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ABSTRACT 


This  project  developed  and  analyzed  the  requirements  for  a  decision  support 
system  capable  of  simulating  future  naval  mine  warfare  scenarios.  As  the  U.S.  Navy 
explores  replacing  legacy  naval  mines  with  new  systems  of  undersea  weapons,  it  requires 
the  supporting  tools  to  evaluate  and  predict  the  effectiveness  of  these  system  concepts. 
While  current  naval  minefield  modeling  and  simulation  capabilities  provide  planners  with 
the  capability  to  design  and  evaluate  the  effectiveness  of  minefields  using  legacy  naval 
mine  capabilities,  they  are  not  adequate  for  the  planning  and  performance  modeling  of 
new  concepts  under  consideration.  The  project  addressed  gaps  in  the  Navy’s  capability  to 
simulate  mine  warfare  scenarios  involving  arrays  of  distributed  sensors  linked  with 
autonomous  mobile  weapons  by  reviewing  the  current  innovations  in  naval  mine  warfare 
development,  verifying  the  gap  in  current  modeling  and  simulation  capabilities,  and  using 
systems  engineering  processes  to  derive  solution  requirements.  Analysis  conducted  using 
prototype  simulation  capabilities,  developed  as  part  of  this  project,  indicates  that  these 
future  systems  will  likely  outperform  legacy  mine  systems  at  a  competitive  cost. 
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EXECUTIVE  SUMMARY 


The  main  purpose  of  sensor  networks  is  to  utilize  the  distributed  sensing 
capability  provided  by  tiny,  low  powered  and  low-cost  devices.  (Jamshidi 
2009,  20) 

In  future  concepts  of  undersea  warfare,  traditional  mine  warfare  systems  may  be 
replaced  with  networks  of  sensors  providing  information  to  mobile,  intercept-to-engage 
weapons.  While  current  naval  minefield  modeling  and  simulation  capabilities  provide 
planners  with  the  capability  to  design  and  evaluate  the  effectiveness  of  minefields  using 
legacy  naval  mine  capabilities,  they  are  not  adequate  for  planning  and  assessing  the 
performance  of  new  concepts  under  consideration  (Ponirakis  2014).  The  Modeling 
Engagements  of  Nodal  Targeting  And  Logic:  Flexible  Options  for  Continued  Undersea 
Superiority  (Mental  Focus)  team  used  systems  engineering  principles  to  identify  and 
address  this  gap  in  the  Navy’s  ability  to  predict  and  evaluate  the  performance  potential  of 
these  future  mine  warfare  architectures. 

The  Mental  Focus  team  identified  the  system  requirements  for  a  simulation 
system  capable  of  predicting  the  performance  of  these  future  systems  and  evaluating  their 
mission  effectiveness.  Appling  Model-Based  Systems  Engineering  (MBSE)  principles, 
the  team  developed  a  conceptual  architecture  model  and  used  it  to  validate  the 
completeness  and  consistency  of  proposed  top-level  requirements.  The  team  used 
software  engineering  techniques  to  develop  a  prototype  simulation  system,  demonstrating 
the  conceptual  solution  approach. 

Finally,  the  team  used  the  prototype  simulation  system  to  conduct  an  initial 
analysis  of  the  potential  benefits  of  future  mine  warfare  architectures.  Using  the 
prototype  simulation  system,  the  team  compared  the  performance  of  a  legacy  mine 
system  and  a  future  undersea  weapon  system  (FUWS)  of  distributed  sensors  linked  with 
autonomous  mobile  weapons.  The  team’s  analysis  showed  that  the  FUWS  could  provide 
improved,  sustained  performance  compared  to  the  legacy  mine  system.  The  prototype 
simulation  system  showed  the  threat  presented  to  the  enemy  by  a  legacy  mine  system 
decayed  exponentially  as  sequential  enemy  vessels  forced  a  channel  through  the 


xix 


minefield.  In  the  scenarios  considered,  by  the  sixth  transiting  vessel  less  than  20%  of  the 
original  threat  remained,  despite  the  fact  that  upwards  of  90%  of  the  mines  remained  in 
the  minefield.  The  FUWS,  however,  continued  to  present  a  significant  threat  to  each 
vessel  transiting  the  minefield,  decaying  only  as  the  weapons  in  the  system  were 
exhausted.  The  increased  threat  presented  by  FUWS  and  its  ability  to  sustain  that  threat 
are  functions  of  the  FUWS  architecture  and  how  it  employs  a  many-to-many  relationship 
between  sensors  and  weapons. 

The  team  contends  that  the  change  in  the  performance  characteristics  resulting 
from  the  change  in  system  architecture  warrants  a  reconsideration  of  the  simple  initial 
threat  (SIT)  as  the  principal  minefield  measure  of  performance.  When  both  architectures 
provide  similar  ranges  of  initial  threats  to  the  first  vessel,  the  sustained  capability  of  the 
FUWS  results  in  a  significantly  higher  enemy  expected  casualties  (EC). 


With  regard  to  narrow  passes,  if  you  can  occupy  them  first,  let  them  be 
strongly  garrisoned  and  await  the  advent  of  the  enemy.  (Sun  Tzu) 
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I. 


INTRODUCTION 


Currently,  there  are  a  number  of  gaps  within  minefield  planning, 
modeling,  and  simulation  capabilities.  With  the  emergence  of  new  mining 
technologies,  new  software  methodologies  are  needed  to  investigate 
capabilities,  drive  new  requirements  and  measures  of  effectiveness, 
address  training  needs,  and  to  meet  Navy  strategic  goals.  (Ponirakis  2014) 

In  U.S.  Navy  doctrine,  mine  warfare  (MIW)  includes  both  the  use  of  sea  mines  to 
project  power  and  shape  enemy  behavior  and  the  use  of  various  systems  and  tactics 
required  to  defeat  and  deny  the  enemy’s  use  of  mines.  Figure  1  shows  this  hierarchy, 
overlapped  with  the  two  Joint  Capability  Areas  (JCAs)  provided  by  MIW.  Over  the  past 
few  decades,  the  Navy  has  invested  significantly  more  resources  in  Mine 
Countermeasures  (MCM)  as  a  Force  Protection  capability  than  in  sea  mines  as  a  principal 
Force  Application  capability1  (Committee  for  Mine  Warfare  Assessment  2001,  36). 
Recently,  however,  the  Navy  has  expressed  renewed  interest  in  sea  mines  as  means  of 
Force  Application  and  has  begun  to  explore  new  concepts  of  sea  mines  that  leverage 
recent  technological  advances  (Holmes  et  al.  2014,  7).  This  project  developed  system 
requirements  for  the  modeling  and  simulation  systems  required  to  support  development 
and  employment  of  these  future  mining  capabilities. 


Figure  1 .  Mine  Warfare  Hierarchy  (adapted  from  NWP  3-15) 


1  This  disparity  in  focus  is  not  only  seen  in  the  allocation  of  financial  resources.  The  current  mine 
warfare  strategic  guidance,  21st-Century  U.S.  Navy  Mine  Warfare,  dedicates  over  95%  of  the  document  to 
MCM  capabilities  and  less  than  5%  to  mining  capabilities. 
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As  the  Navy  explores  these  new  concepts  of  sea  mine  capabilities,  it  requires  the 
supporting  tools  to  evaluate  and  predict  the  effectiveness  of  the  concepts.  Current  naval 
minefield  modeling  and  simulation  capabilities  provide  planners  with  the  capability  to 
design  and  evaluate  the  effectiveness  of  minefields  using  legacy  naval  mine  capabilities. 
These  tools,  however,  are  not  adequate  for  the  planning  and  performance  modeling  of 
new  concepts  under  consideration  (Ponirakis  2014).  This  report  reviews  the  current  status 
in  naval  mine  warfare  development,  verifies  the  gap  in  modeling  and  simulation 
capability,  and  uses  system  engineering  processes  to  derive  solution  requirements.  These 
system  requirements  are  provided  to  the  Navy  to  inform  future  capability  development 
efforts. 

A.  BACKGROUND 

The  sea  mine  was  introduced  during  the  American  Revolution  and  the 
land  mine  during  the  American  Civil  War.  Both  are  products  of  American 
ingenuity.  In  1970,  absent  a  fitting  definition,  the  National  Academy  of 
Sciences’  Mine  Advisory  Committee  defined  the  mine  as  a  “weapon  that 
waits.”  (Hunt  1998) 

From  the  Bushnell  brothers’  1778  attack  on  the  British  fleet  with  kegs  of 
gunpowder  fitted  with  contact  fuses  (PEO  LMW  2009,  3)  to  the  1991  deployment  of 
Quickstrike2  mines  in  the  northern  Arabian  Gulf  (6),  the  sea  mine  has  been  the  original 
“long-endurance  robotic  warrior”  (Hunt  1998).  Once  deployed,  the  mine  “waits”  with  a 
degree  of  autonomy  available  in  few  other  weapon  systems. 

As  general  technological  development  accelerated  in  the  last  60  years,  sea  mine 
technological  development  has  been  comparatively  stagnant.  The  last  revolutionary 
advancement  in  sea  mine  capabilities  was  the  introduction  of  the  bottom  influence  mine 
during  World  War  II;  today’s  legacy  mines  largely  represent  1960s  technology  (Hunt 
1998).  As  recently  as  2009,  the  Navy’s  official  strategy  for  naval  mining  capability 
development  was  entirely  focused  on  upgrading  the  Quickstrike  mine  with  an  improved 
firing  mechanism,  the  Mk  71  Target  Detection  Device  (TDD).  While  the  TDD  provided 

2  Originally  deployed  during  the  Vietnam  War,  the  aircraft  deployed,  bottom  influence  Quickstrike 
family  of  naval  mines  comprises  the  legacy  mining  capability  of  the  Navy.  The  Quickstrike  family  includes 
the  Mk  62  and  Mk  63  converted  bombs  and  the  Mk  65  dedicated  thin  wall  mine  (PEO  LMW  2009,  25). 
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evolutionary  improvements  to  the  sensor,  targeting  logic,  and  counter-countermeasures 
capabilities  (PEO  LMW,  25-26),  it  did  not  fundamentally  change  the  mine’s  architecture 
or  planning  parameters.  Sea  mines  remain  fixed,  isolated,  explode-in-place  weapon 
systems  virtually  unchanged  for  over  half  a  century. 

The  application  of  recent  technological  developments  in  solid-state  electronics 
miniaturization,  reliable  undersea  communication,  and  new  high  yield  explosive 
compounds  to  the  naval  mining  problem  has  the  potential  to  reinvigorate  development  of 
sea  mine  capabilities  and  introduce  radical  changes  to  the  legacy  architecture  (Hunt 
1998).  The  successor  to  today’s  explode-in-place  mines  will  likely  rely  less  on  the  paired 
sensor-weapon  architecture  and  more  on  an  array  of  distributed  sensors  linked  with 
mobile  weapons  in  a  networked  architecture.  To  evaluate  and  quantify  the  potential 
benefits  of  this  radical  change  in  future  naval  mine  system  architectures,  this  project 
focused  on  the  engineering  and  conceptual  design  of  a  software  system  capable  of 
modeling  these  future  systems  and  evaluating  their  effectiveness. 

The  Modeling  Engagements  of  Nodal  Targeting  And  Logic:  Flexible  Options  for 
Continued  Undersea  Superiority  (Mental  Focus)  Simulation  Application  (MFSA) 
provides  the  user  with  the  ability  to  determine  the  effectiveness  of  planned  configurations 
of  sensors  and  weapons  available  in  a  futuristic  net-centric  naval  mine  system.  Because 
this  technologically  advanced  architecture  provides  for  new  emergent  capabilities,  the 
MFSA  evaluates  new,  more  complex,  measures  of  effectiveness  (MOEs)  in  addition  to 
the  traditional  minefield  MOEs. 

B.  FUTURE  UNDERSEA  WEAPON  SYSTEM  (FUWS) 

The  Advanced  Undersea  Weapon  System  (AUWS)  is  a  group  of 
unmanned  systems  (sensors,  effectors,  communications,  and  vehicles)  that 
can  be  pre -positioned  to  autonomously  and  persistently  influence  the 
adversary  at  a  time  and  place  of  our  choosing.  (Edwards  and  Gallagher 
2014) 

During  his  2009  “State  of  Mine  Warfare”  annual  presentation  to  the  CNO,  the 
Commander  Naval  Mine  and  ASW  Command  (NMAWC),  RADM  Frank  Drennan, 
coined  the  concept  of  Advanced  Undersea  Weapons  System  (AUWS).  RADM  Drennan 
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noted  that  naval  “mines”  should  no  longer  be  thought  of  as  dumb,  immobile  weapons 
waiting  for  unsuspecting  mariners  to  run  into  them;  but  rather,  that  existing  and 
developing  technologies  could  transform  the  historic  naval  mine  into  a  system  of 
distributed  sensors  and  moveable  weapons  with  vastly  improved  capability.  In  2010- 
2011  the  Naval  Postgraduate  School  System  Engineering  Analysis  Cohort  17,  Team  B 
(SEA17B),  developed  and  analyzed  AUWS  as  an  alternative  concept  for  providing 
undersea  warfare  (USW)  dominance  (Emmersen  et  al.  2011,  vii).  The  AUWS  concept 
provides  an  innovative,  flexible,  modular  system  of  systems  approach  to  future  naval 
mining  capabilities.  Because  it  provides  a  useful  architecture  for  what  a  future  naval  mine 
system  may  look  like,  the  Mental  Focus  project  used  this  future  concept,  as  articulated  by 
SEA17B,  as  a  representative  instantiation  of  a  potential  future  system  of  systems 
approach  to  naval  mine  warfare.  The  term  AUWS  has  since  been  adopted  by  the  Office 
of  Naval  Research  (ONR)  as  a  particular  research  and  development  program  (Everhart 
2012),  the  Advanced  Undersea  Weapon3  System.  Because  of  the  potential  ambiguity 
associated  with  the  AUWS,  the  Mental  Focus  project  used  the  umbrella  term  Future 
Undersea  Weapon  System  (FUWS)  to  describe  a  broad  set  of  possible  concepts, 
including  the  instantiations  of  AUWS.  This  allowed  the  project  to  leverage  the 
conceptual  approach  of  SEA17B  without  being  tied  to  the  particular  architecture  selected 
by  ONR. 

As  shown  in  the  high-level  operational  concept  (Figure  2),  this  notional  advanced 
mining  system  of  systems  promises  increased  flexibility,  relative  to  legacy  minefields,  by 
employing  distributed  sensors  and  modular  effectors4  to  generate  desired  tactical  and 
operational  effects.  Figure  2  shows  a  distributed  sensor  network  detecting  the  presence  of 
a  submerged  threat  target.  The  sensors  communicate  the  presence  of  the  threat  to  a 
weapon,  such  as  the  encapsulated  torpedo  on  the  right,  which  then  engages  the  target 
al.so  shown  in  Figure  2  is  a  surface  warship  detected  by  the  distributed  sensor  network. 


3  Note  the  change  from  warfare  system  to  weapon  system.  This  project  used  the  term  weapon  system 
to  describe  a  physical  system  procured  and  employed  to  deliver  a  military  capability.  The  term  warfare 
system  is  used  to  describe  the  systematic  employment  of  the  art  and  science  of  operational  warfare. 

4  Effector  is  a  term  used  to  describe  mines  or  weapon  payloads  in  the  AUWS  architecture  (SEA17B 
2011,  32).  This  term  is  used  interchangeably  with  mine  and  weapon  payload  throughout  the  project. 
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The  system  has  yet  to  engage  this  target,  but  it  may  soon  direct  engagement  with  the 
weapons  battery  in  the  lower  left  of  the  figure  when  the  target  meets  engagement  criteria. 
While  Figure  2  shows  a  FUWS  deployed  in  a  seaport  closure  scenario,  where  the 
operational  commander  is  attempting  to  deny  the  enemy  access  to  and  from  their  own 
seaport  (offensive  mining),  the  FUWS  concept  may  also  be  used  to  influence  enemy 
operational  behavior  in  the  defense  of  friendly  seaports  (protective  mining)  as  well  as  in 
open-ocean,  area-denial  scenarios  (defensive  mining). 


Figure  2.  FUWS  Operational  Concept  (adapted  from  Everhart  2012) 


C.  CAPABILITY  GAP 

Capability  Gap — The  inability  to  meet  or  exceed  a  capability  requirement, 
resulting  in  an  associated  operational  risk  until  closed  or  mitigated.  The 
gap  may  be  the  result  of  no  fielded  capability,  lack  of  proficiency  or 
sufficiency  in  a  fielded  capability  solution,  or  the  need  to  replace  a  fielded 
capability  solution  to  prevent  a  future  gap.  (CJCSI  3170.011  2015) 

There  are  a  variety  of  potential  FUWS  weapons  configurations  that  leverage 
existing  and/or  developmental  technologies  varying  in  size,  cost,  complexity,  lethality, 
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range,  and  speed.  In  some  scenarios,  it  may  be  necessary  to  increase  weapon  quantity, 
with  range  and  lethality  being  less  important.  While  in  other  scenarios,  a  larger  explosive 
charge  in  combination  with  increased  range  and  speed  may  be  more  likely  to  produce  the 
required  effects.  Each  weapon  payload  has  different  performance  characteristics,  which 
will  allow  the  overall  system  of  systems  to  be  tailored  for  a  particular  desired  mission 
outcome. 

In  order  to  develop  and  employ  such  systems  in  an  effective  manner,  the  Navy 
requires  a  decision-support  simulation  system  that  accurately  models  the  detection  of  a 
target,  decision  logic,  communication  of  target  parameters,  and  engagement  of  the  target 
with  a  selected  weapon.5  Without  establishing  a  properly  abstracted  simulation  system 
architecture,  it  will  be  difficult  to  establish  realistic  decision-support  system-level 
performance  requirements  and  the  associated  subsystem  allocated  requirements. 
Additionally,  operational  planners  need  the  ability  to  develop  mine  employment  plans 
and  accurately  predict  the  effectiveness  of  planned  configurations  of  weapons  and 
sensors. 

D.  PROJECT  SCOPE 

The  project  scope  was  based  on  addressing  this  gap  in  mine  simulation  and 
planning  capability  using  available  resources.  The  MFSA  high-level  operational  concept 
(Figure  3)  provides  a  graphical  representation  of  the  MFSA  in  operation. 

The  MFSA  system  provides  warfare  center  program  analysts  and  capability 
developers  the  ability  to  understand  and  optimize  the  effectiveness  of  a  particular 
configuration,  supporting  alternative  analysis  and  informing  capability  development.  The 
MFSA  also  provides  minefield  planners  at  reach-back  support  commands  the  ability  to 
optimize  the  effectiveness  of  a  particular  configuration,  supporting  operational  decisions 
and  tactical  system  deployment. 

However,  because  the  project  was  not  resourced  to  deliver  a  mature,  fully 
functional,  and  integrated  decision  support  system,  the  Mental  Focus  team  focused  efforts 

5  The  applicable  required  JCA  is  5.3.5  Analyze  Courses  of  Action:  The  ability  to  evaluate  potential 
solutions  to  determine  likelihood  of  success. 
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on  MFSA  requirement  analysis  and  architecture  development.  The  project  team  used  a 
prime  directive  statement  to  ensure  efforts  remained  focused  on  the  MFSA  statement  of 
need,  project  goals  to  communicate  the  desired  project  end  state,  and  a  prototype 
simulation  system  to  visualize  and  demonstrate  the  system  requirements  and  architecture. 


SIMULATION  TOOL 


Figure  3.  MFSA  Operational  View  (OV-1) 


During  the  literature  review,  the  project  team  determined  that  most  current  efforts 
in  the  AUWS  concept  development  have  been  directed  at  analyzing  the  required  sensor 
systems  and  that  significantly  less  effort  was  being  focused  on  the  required  weapon 
system  components.  By  focusing  on  the  weapons  portion  of  the  FUWS  concept,  the 
analytic  efforts  of  the  Mental  Focus  project  contribute  to  capability  developer 
understanding  at  stakeholder  organizations.  This  helps  to  shape  the  U.S.  Navy’s  future 
undersea  warfare  capabilities  and  directly  supports  the  Chief  of  Naval  Operations’ 
(CNO’s)  vision  of  continued  undersea  dominance  (Greenert  2011,  2). 

MFSA  will  provide  stakeholders  with  the  ability  to  evaluate  alternative  FUWS 
configurations  in  various  mission  scenarios  and  optimize  the  system  performance  to 
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achieve  desired  operational  effectiveness.  Capability  developers  may  use  the  tool  to 
evaluate  alternative  tactics  and  materiel  components,  support  development  of  future 
undersea  weapon  systems  and  inform  development  priorities. 

1.  System  Context  and  Prime  Directive 

As  shown  in  the  MFSA  context  diagram  (Figure  4),  the  project  focused  on  the 
requirements  of  the  proposed  simulation  application.  The  system  uses  information  about 
the  available  FUWS  component  architecture,  information  about  the  environment,  and 
information  about  the  intended  mission  employment  to  provide  an  optimized  deployment 
configuration.  The  system  interfaces  with  various  users  including  analysts,  maintainers, 
and  operational  decision  makers. 


To  keep  the  project  efforts  focused  on  the  required  system  capability,  the  team 
developed  the  following  high-level  statement  of  purpose,  or  prime  directive: 

Analyze  and  compare  system  configurations6  to  inform  the  development 
and  employment7  of  distributed  sensors  and  networked  effectors  in  the 
undersea  environment.8 


6  Applicable  Universal  Joint  Tasks  (UJTs)  are  Analyze  Courses  of  Action  (OP  5.3.5)  and  Compare 
Courses  of  Action  (OP  5.3.6). 

7  Applicable  UJT  is  Tailor  Forces  (ST  7.1.3). 

8  Applicable  Universal  Naval  Task  is  Plan  Minefields  (NTA  1.4. 1.1). 


This  directive  was  useful  in  developing  the  project  study  questions  and  goals  and 
in  communicating  the  purpose  of  the  proposed  MFSA  system  and  the  required  simulation 
capability.  The  team  found  the  use  of  a  prime  directive  statement  useful  in  focusing 
project  efforts  and  minimizing  distractions  outside  the  MFSA  scope.  By  mapping  the 
prime  directive  to  appropriate  joint  and  service  tasks,  the  team  ensured  traceability  and 
alignment  with  stakeholder  organizational  goals. 

2.  Study  Questions 

The  following  study  questions  were  used  to  guide  the  project  efforts: 

1.  What  capabilities  does  a  networked  sensor-weapon  system  provide  over 
the  existing  legacy  mine  capability? 

2.  What  emergent  behavior  results  from  modular  networks  of  sensors  and 
weapons? 

3.  What  are  the  necessary  sequences  of  events  that  must  be  modeled  in  a 
FUWS  architecture  to  simulate  mission  scenarios? 

4.  What  parts,  if  any,  of  existing  models  or  simulation  systems  for  undersea 
warfare  could  be  reused  or  integrated  into  MFSA? 

3.  Goals  and  Objectives 

The  following  project  team  goals  and  objectives  were  used  to  scope  project 
stakeholder  expectations  and  define  the  anticipated  project  end  state.  They  represent  the 
level  of  MFSA  development  the  team  anticipated  available  resources  could  support. 

1.  Apply  Model-Based  Systems  Engineering  (MBSE)  principles  to  the 
development  of  the  MFSA  architecture  conceptual  design. 

2.  Identify  requirements  for  the  MFSA  conceptual  architecture. 

3.  Develop  model(s)  that  represent  the  sequence  of  targeting  and  decision 

events  in  a  mining  scenario  from  sensing  the  presence  of  a  vessel  to 
engaging  a  threat. 

4.  Develop  a  prototype  simulation  system  to  demonstrate  the  conceptual 
architecture  and  to  support  requirement  discovery. 

5.  Investigate  which  measures  of  effectiveness  are  most  applicable  for 
evaluating  advanced  undersea  weapons  systems. 
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4.  Assumptions  &  Constraints 

The  following  assumptions  and  constraints  were  explicitly  identified  in  the 
scoping  of  the  project: 

1.  The  SEA17B  AUWS  concept  is  just  one  possible  instantiation  of  a  future 
system.  MFSA  must  be  applicable  to  other  potential  systems  as  well. 

2.  All  data  required  as  inputs  for  the  decision  support  system  already  exists 
and  is  accessible  by  government  personnel  and/or  systems  with  proper 
security  clearances. 

3.  Current  commercial-off-the-shelf  desktop  computers  provide  sufficient 
computational  processing  power  for  use  by  the  decision  support  system. 

4.  The  consideration  of  potential  future  weapon  system  components  can  be 
limited  to  currently  fielded  technologies  and  to  technologies  that  can  be 
realistically  fielded  within  the  next  10  years. 

5.  The  MFSA  requirement  development  process  would  remain  solution 
neutral.  While  the  MFSA  capability  may  be  affordability  implemented  by 
upgrading  or  modifying  an  existing  system,  the  project  would  not  assume 
this. 

6.  The  development  of  a  demonstration  system  would  be  constrained  by  the 
team’s  limited  resources,  including  limited  software  programming 
experience. 

E.  APPROACH  AND  METHODOLOGY 

By  clearly  articulating  the  value  of  networked  sensor-weapon  system  over  the 
existing  legacy  capabilities,  this  project  enhanced  the  Navy’s  knowledge  of  persistent 
undersea  warfare.  This  section  describes  the  approach  and  methodology  that  the  project 
team  took  as  a  means  to  accomplish  the  goals,  meet  the  objectives  and  achieve  the 
desired  benefits  of  the  project. 

1.  Project  Process 

Figure  5  shows  the  simulation  system  development  process  used  by  the  Mental 
Focus  team. 
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Figure  5.  Project  Process  Map  (adapted  from  Heath  et  al.  2009) 


Adapted  from  process  maps  used  for  simulation  system  development,  this  process 
highlights  the  steps  conducted  as  part  of  this  project.  With  limited  project  resources,  the 
team  chose  to  focus  on  development  of  system  requirements  and  supporting  conceptual 
model.  This  report  provides  documentation  of  the  project  team’s  efforts  and  is  provided 
to  support  execution  of  the  remainder  of  the  development  process. 
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2. 


Team  Organization 


The  Mental  Focus  project  team  was  composed  of  four  Naval  Postgraduate  School 
graduate  students,  identified  in  Table  1,  guided  by  two  faculty  advisors.  The  team 
included  members  of  diverse  backgrounds,  but  all  with  experience  in  the  development 
and  application  of  naval  warfare  systems.  The  team  also  had  significant  background 
experience  and  interest  in  the  undersea  domain. 


Table  1.  Team  Mental  Focus 


Team 

Member 

Prior 

Degree 

Command/Employment 

John 

Glisson 

VA  Tech, 
BSME  ‘05 

Assistant  Program  Manager,  Mine  Warfare  Program 
Office  (PMS  495) 

Nathan 

Hagan 

Webb  Inst, 

BS  NAME  ‘12 

Naval  Architect  for  the  Structural  Criteria  and  Risk 
Assessment  Branch,  Naval  Surface  Warfare  Center, 
Carderock  Division,  West  Bethesda 

Alyson 

Ledder 

Temple, 

BBA  Econ  ‘10 

Program  Analyst  providing  contractor  support  to 
Submarine  Mast  Mechanical  System  ISEA  at  Naval 
Surface  Warfare  Center,  Philadelphia 

Robert 

Patchin 

Gonzaga, 

BSME  ‘99 

Submarine  Warfare  officer  assigned  to  the  Joint  Staff 

J8  as  an  analyst  supporting  the  Force  Support 

Functional  Capabilities  Board 

In  order  to  provide  structure  and  accountability,  specific  team  roles  and 
responsibilities  were  identified  for  each  team  member,  shown  in  Table  2,  as  part  of  the 
project  planning  process.  These  team  assignments  were  selected  to  leverage  individual 
expertise  and  skills  as  well  as  team  member  interests.  To  ensure  equitable  participation 
with  the  small  team  size,  each  team  member  also  participated  in  every  aspect  of  the 
project  development  and  execution. 
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Table  2.  Team  Roles  and  Responsibilities 


Team 

Member 

Role 

Responsibilities: 

John 

Glisson 

System 

Architect 

Coordinated  system  architecture  design  and  development 
Conducted  technical  briefings 

Nathan 

Hagan 

Team  Lead 

Conducted  team  meetings 

Tracked  project  deliverables  and  schedule  progress 
Updated  and  liaised  with  stakeholders  and  advisors 
Identified  and  assigned  additional  duties  as  required 

Alyson 

Ledder 

Modeling 

Lead 

Selected  Modeling  and  Simulation  tools  and  methods 
Coordinated  Modeling  and  Simulation  efforts  and 
analysis 

Robert 

Patchin 

Editor  and 
Programmer 

Coordinated  final  editing  and  submitted  team  reports 
Programmed  prototype  simulation  system 

3.  Literature  Review 

Early  in  the  project,  the  team  conducted  a  thorough  literature  review  focused  on 
establishing  a  baseline  understanding  of  the  current  strategic,  programmatic,  and 
academic  efforts  in  development  of  persistent,  distributed  undersea  weapon  systems.  The 
project  team  also  reviewed  the  modeling  and  theory  of  wide-area  sensor  networks  and 
targeting-decision  logic.  These  reviews  of  prior  work  helped  establish  the  project  team’s 
subject  matter  knowledge  base  and  ensured  the  relevance  of  the  project  goals  to  current 
efforts. 


While  many  of  the  sources  reviewed  are  included  in  the  list  of  references,  the 
project  team  felt  it  beneficial  to  highlight  the  following  sources,  as  they  contributed 
significantly  to  the  MFSA  development: 

•  Emmersen,  Tracy,  Ng  Kiang  Chuan,  David  Chiam,  Ong  Zi  Xuan,  Perh  Hong  Yih 
Daniel,  Koh  Wee  Yung,  Wes  Wessner,  et  al.  2011.  “Advanced  Undersea 
Warfare  Systems.”  Master’s  thesis,  Naval  Postgraduate  School. 
http://hdl.handle.net/10945/6959. 

This  Naval  Postgraduate  School  (NPS)  Systems  Engineering  capstone  project 
focused  on  design  of  an  advanced  undersea  warfare  system  architecture,  shaping 

much  of  the  current  AUWS  developmental  efforts.  The  functional  decompositions 
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and  dendritic  models  provided  useful  architectures  for  understanding  the  AUWS 
concept.  Mental  Focus  built  on  this  project  by  modeling  combinations  of  sensors 
and  actors  (weapons).  Specifically,  MFSA  provides  the  tool  necessary  to  optimize 
the  system  architecture  (69-70)  for  a  variety  of  design  reference  missions 
(DRMs). 

•  Bard,  William.  2013.  “Naval  Minefield  Modeling  and  Simulation:  An 
Examination  of  General  Analytical  Minefield  Tool  (GAMET)  and  Other 
Minefield  Models.”  Naval  Postgraduate  School. 

This  NPS  Operations  Research  master’s  thesis  examined  a  government  off-the- 
shelf  (GOTS)  tool  for  calculation  of  minefield  system  effectiveness.  William 
Bard’s  thesis  provided  a  valuable  source  for  the  team’s  understanding  of  current 
minefield  simulation  capabilities.  His  description  of  functionality  and  capability 
of  GAMET  (17-22)  provided  a  foundation  for  much  of  the  project’s  capability 
gap  analysis  and  capability  development  efforts. 

4.  Methods 

The  project  team  recognized  that  successful  development  of  the  MFSA  system 
would  involve  not  only  general  systems  engineering  (SE)  practices,  but  also  Model- 
Based  Systems  Engineering  (MBSE)  and  software  engineering  methodologies.  As  shown 
in  Figure  6,  the  successful  conceptual  design  development  of  MFSA  was  accomplished 
using  an  integrated  interdisciplinary  approach.  The  methodologies  and  approaches 
leveraged  from  each  discipline  are  shown  in  Table  3.  The  selected  methods  support  a 
holistic  evolutionary  process  model  for  MFSA  software  development.  The  team’s  early 
inclusion  of  software  engineering  methods,  including  the  development  of  a  prototype 
system  to  support  refinement  of  requirements,  was  intended  to  support  rapid  transition  to 
MFSA  development.  Within  the  talents  and  resources  available  to  the  team,  the  team 
developed  a  demonstration  prototype,  simulating  the  first  sprint  in  a  scrum  development 
effort  (Pressman  2015,  79). 


14 


Table  3. 

Methods  Employed  by  the  Mental  Focus  Project 

Discipline 

Method 

SE 

Consultations  with  Subject  Matter  Experts  (SMEs)  to  understand 
stakeholders  needs  and  concerns 

SE 

Determination  of  Key  Performance  Parameter  (KPP)  requirements 

SE 

Determination  of  the  evaluation  and  extension  of  the  Measures  of 
Performance  (MOP)  of  a  FUWS 

SE 

Performance  of  a  Quality  Function  Deployment  (QFD)  analysis  to 
select  the  prototype  simulation  platform 

MBSE 

Determination  of  MFSA  system  architecture  and  targeting  logic 
requirements  using  MBSE  principles 

MBSE 

Development  of  a  conceptual  system  architecture  expressed  in 

Unified  Modeling  Language  (UML)  and  DOD  Architecture 

Framework  (DoDAF)  products 

Software 

Engineering 

Definition  of  use  case  scenarios  typical  of  the  operational 
environment 

Software 

Engineering 

Agile  development  of  a  system  demonstration  prototype 

General 

Systems 

Engineering 

MFSA 


Software 

Engineering 


Model  Based 
Systems 
Engineering 
(MBSE) 


Figure  6.  Integrated  Interdisciplinary  Approach  to  MFSA  Development 
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II.  CAPABILITY  GAP  ANALYSIS 


Mining  is:  ...  In  naval  mine  warfare,  an  explosive  device  laid  in  the  water 
with  the  intention  of  damaging  or  sinking  ships  or  of  deterring  shipping 
from  entering  an  area.  The  term  does  not  include  devices  attached  to  the 
bottoms  of  ships  or  to  harbor  installations  by  personnel  operating 
underwater,  nor  does  it  include  devices  that  explode  immediately  on 
expiration  of  a  predetermined  time  after  laying.  (UJTL  2015,  T A  1.4) 

This  chapter  presents  the  Mental  Focus  team’s  analysis  of  the  system  need.  The 
team  identified  and  categorized  capability  stakeholders  to  ensure  the  needs  of  the 
customer  informed  the  team’s  perspective  on  capability  requirements.  The  team  then 
scoped  the  requirements  for  modeling  potential  FUWS  architectures  by  conducting  a 
review  of  potential  architectures.  Finally,  the  team  scoped  the  capability  gap  MFSA 
attempts  to  close  by  identifying  the  shortfalls  in  current  simulation  systems. 

A.  STAKEHOLDER  IDENTIFICATION 

The  Mental  Focus  team  identified  a  number  of  active  stakeholders,  those  that 
would  have  a  direct  interest  in  the  team’s  project,  and  passive  stakeholders,  those  that 
would  have  interest  in  the  future  development  of  the  proposed  system.  These 
stakeholders,  shown  in  Tables  4  and  5,  respectively,  were  initially  identified  during  the 
proposal  development  phase  to  assist  the  team  in  identifying  the  customer  need  for 
FUWS  simulation  capabilities.  Their  roles  and  anticipated  concern  or  interest  with  the 
proposed  capability  development  were  further  refined  during  the  project  stakeholder 
analysis. 

The  Mental  Focus  team  identified  four  active  stakeholder  organizations  that 
formed  the  principal  customer  base  for  the  MFSA  project.  The  missions  and  viewpoints 
of  these  organizations,  as  articulated  in  Table  4,  were  considered  throughout  the  project 
execution.  These  organizations  are  all  actively  involved  in  the  research  and  development 
of  AUWS,  and  have  established  much  of  the  critical  background  information  necessary 
for  the  teams  understanding  of  future  mining  capabilities.  Additionally,  as  the  NPS 
Expeditionary  and  Mine  Warfare  Adviser,  Rear  Admiral  (ret)  Rick  Williams  was  able  to 

validate  the  MFSA  capability  gap  and  problem  statement. 
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Table  4. 


Active  MFSA  Stakeholders 


Stakeholder  Roles  and  Anticipated  Concerns 


Office  of  Naval 
Research  (ONR) 

Project  Customer:  Needs  to  understand  capability  and 
performance  of  various  FUWS  concepts  in  a  range  of  missions 
and  environments 

Concerned  with  technological  challenges  and  development  of 
next  generation  naval  weapon  systems 

Naval  Sea  Systems 
(NAVSEA) 
including  the 
applicable  Program 
Executive  Office 
(PEO)  and 
supporting  program 
offices 

Identified  as  MFSA  system  developer  end  user  organization 

Project  Customer:  Needs  to  understand  capability  and 
performance  requirements  of  various  FUWS  concepts  in  a 
range  of  missions  and  environments 

Concerned  with  efficient  use  of  resources  to  support  the 
research,  development,  acquisition,  and  modernization  of  naval 
weapon  system  capabilities 

Naval  Surface  and 
Mine  Warfighting 
Development  Center 
(SMWDC) 

Identified  as  MFSA  operational  planner  end  user  organization 

Project  Customer:  Articulates  mine  warfare  capabilities 
requirements;  promotes  rapid  delivery  of  new  technologies; 
provides  minefield  planning  capabilities  to  operational  forces 

Concerned  with  operational  employment  of  mine  warfare 
capabilities  and  mine  warfare  mission  performance  metrics 

Naval  Postgraduate 
School  (NPS) 

Faculty 

Project  Governance:  Ensures  project  meets  standards  of 
academic  excellence 

Concerned  with  increasing  combat  effectiveness  of  naval 
services 

The  team  also  identified  a  number  of  passive  stakeholder  organizations  with 

future  roles  in  the  development  and  employment  of  MFSA.  The  missions  and  viewpoints 

of  these  stakeholders,  identified  in  Table  5,  were  also  considered  throughout  the  project 

execution.  While  not  directly  involved  as  the  system  customers,  their  role  in  resourcing 

and  integrating  the  MFSA  system  and  in  implementing  recommended  FUWS  concepts 

will  be  critical  to  the  ultimate  goal  of  improving  warfighter  combat  effectiveness.  During 

MFSA  development,  these  stakeholders  were  considered  primarily  from  their  role  in  the 
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development  and  delivery  of  a  FUWS  informed  by  MFSA.  Their  interests  and  concerns 
were  used  to  validate  the  MFSA  output  requirements. 


Table  5.  Passive  MFSA  Stakeholders 


Stakeholder  Role  and  Anticipated  Concern/Interest 


Joint  Requirements 
Oversight  Council 
(JROC) 

FUWS  Governance:  Validates  joint  weapon  system 
requirements 

Interested  in  efforts  to  exploit  autonomy  in  the  development  of 
future  weapon  systems 

Concerned  with  risk  to  mission  and  affordability 

OPNAV  N9/N95 

FUWS  Governance:  Manages  system  requirements  of  naval 
warfare  systems  and  assigns  resources  for  system  capability 
development  and  maintenance 

Concerned  with  risk  to  mission  and  affordability 

Commander 
Submarine  Forces 

FUWS  Influencer:  Leads  efforts  to  sustain  advantages  in 
undersea  warfare 

Concerned  with  undersea  warfare  readiness 

Military-Industrial 

Complex 

FUWS  Provider:  Builds  and  delivers  undersea  weapon  systems 

Concerned  with  solution  development  and  profitability 

Joint  Force  Maritime 
Component 
Commander 
(JFMCC)  and  Staff 

FUWS  Integrator:  Establishes  undersea  warfare  goals  and 
priorities 

Concerned  with  the  ability  to  project  power  from  the  Sea  and 
optimizing  employment  of  assigned  assets 

Undersea  Warfare 
Commander  and 

Staff 

FUWS  Integrator:  Directs  use  of  undersea  systems  in  the 
operational  theater 

Concerned  with  flexibility,  mission  effectiveness,  and 
probability  of  kill 
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B.  FUWS  ARCHITECTURE  REVIEW 


The  greatest  warfighting  return  will  be  generated  by  proper  investment  in 
future  USW9  payloads.  The  attributes  that  will  provide  that  return  are 
endurance  and  autonomy,  (emphasis  added,  Connor  2013) 

To  support  the  required  simulation  of  future  mining  systems,  the  Mental  Focus 
team  needed  to  understand  the  key  elements  of  an  advanced  mining  architecture.  To  this 
end,  the  team  extensively  leveraged  the  SEA17B  NPS  capstone  project,  “Advanced 
Undersea  Weapons  System”  (Emmersen  et  al.,  2011).  In  comparison  with  the  ONR 
AUWS  architecture  under  development,  the  SEA17B  architecture  provides  a  more 
academic,  solution  neutral  architecture  at  the  unclassified  level.  As  such,  the  project  team 
used  the  SEA17B  architecture  as  the  foundation  for  a  robust,  accessible  FUWS 
architecture  at  an  appropriate  level  of  abstraction  to  support  MFSA  requirement  analysis. 

1.  Functional  Context 

Consistent  with  the  project’s  scope  and  operational  concept  (Figure  3),  the  Mental 
Focus  team  used  the  FUWS  functional  context  to  describe  the  level  of  abstraction 
required  for  modeling  by  the  MFSA  system.  Specifically,  in  order  to  inform  development 
priorities  and  predict  operational  effectiveness,  MFSA  must  model  the  FUWS  functional 
behavior  as  well  as  the  relevant  energy,  material  and  information  (EMI)  interfaces. 
Modeling  at  a  less  detailed  level  of  abstraction,  such  as  the  inclusion  of  FUWS 
capabilities  in  a  campaign  level  model,  or  at  more  detailed  levels,  such  as  the  physics 
modeling  of  hydro-acoustic  transmission,  would  be  outside  the  identified  capability  gap 
and  intended  MFSA  scope. 

As  seen  in  Figure  7,  the  functional  context  established  by  SEA17B  used  four 
principal  groupings  of  EMI  interfaces. 

•  Controllable  Inputs:  those  inputs  and  triggers  that  can  be  controlled  either  by  the 
system  developer  or  operational  user. 

•  Uncontrollable  Inputs:  those  inputs  and  triggers  that  are  part  of  the  undersea 
environment  or  are  controlled  by  the  enemy. 


9  In  U.S.  Navy  Doctrine  undersea  warfare  (USW)  includes  mine  warfare,  submarine  warfare,  and  anti¬ 
submarine  warfare. 
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•  Intended  Outputs:  those  outputs  required  by  the  operational  user  and  designed  by 
the  system  developer. 

•  Byproducts:  those  emergent  outputs  resulting  from  the  system  behavior  that  must 
be  mitigated  (undesirable  to  the  customer)  or  could  exploited  (desirable  to  the 
customer). 


idefiD  FUWS 10  [After  SEA17B  2011  Figure  3. 16] 


Uncontrollable  Inputs  | 
Contact  Signature 
Unknown  Threat  Tactics 
Weather 
Environmental 


Controllable  Inputs  | 
Power  Consumption 
Operator  Inputs 
System  Parameters 
Mission  Data 
Training  Meathods 
Peer  System  Inputs 


Intended  Outputs  | 
Threat  Classification 
Threat  Prioritized 
Mobilization  of  Kinetic 
Subsystem 

Automated  Engagement 
if  Threat 

Threat  Elimination 
Sensor  Data 
Communication,  with 
Command  and  Control 
Battle  Damage 
Assessment 


By-Products  | 
Unintended  Casualties 
Stray  Signals 
Impact  on  Ecosystem 


Date: 


University  Edition  -  For  Academic  Use  Only 


August  12,  2015 


Figure  7.  FUWS  Functional  Context  (adapted  from  SEA17B  2011) 


These  inputs  and  outputs,  and  the  associated  EMI  interfaces,  were  reviewed  by 
the  team  and  considered  for  modeling  in  MFSA.  Those  inputs  required  to  support  the 
FUWS  targeting  logic  and  those  outputs  required  to  support  identified  measures  of 
effectiveness  (MOEs)  were  prioritized  for  modeling  in  MFSA  as  detailed  in  Chapter  III. 
The  remaining  inputs,  outputs,  and  byproducts  should  be  considered  in  enhancing  the 
MFSA  utility,  but  they  were  not  considered  as  customer  requirements  based  on  the 
identified  stakeholders. 

2.  Functional  Architecture 

Having  bounded  the  modeling  problem  with  the  FUWS  functional  context,  the 
team  needed  to  understand  and  define  the  functional  behavior  occurring  within  the 
FUWS  system  boundary.  Again,  by  leveraging  the  SEA17B  project’s  functional 
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decomposition,  the  Mental  Focus  team  was  able  was  able  to  develop  a  solid 
understanding  of  the  required  functional  flow  of  a  FUWS.  Figure  8  provides  the  SEA17B 
Enhanced  Functional  Flow  Block  Diagram  (EEFBD)  showing  the  high  level, 
architectural  functions  performed  by  FUWS.  Of  note,  the  system  is  responsible  for 
performing  a  variety  of  functions  simultaneously,  independent  of  the  presence  of  a  threat. 


effbd  Conduct  FUWS  Operations  [After  SEA17B  2011  Figure  3. 15] 
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Figure  8.  FUWS  High  Level  EFFBD  (adapted  from  SEA17B  201 1) 


The  Mental  Focus  team  also  conducted  a  parallel  review  of  the  Universal  Joint 
Task  List  (UJTL)  and  Universal  Naval  Task  List  (UNTL)  to  establish  traceability  of 
FUWS  capabilities  to  mission  requirements  (Appendix  A).  As  a  result  of  this  review,  the 
team  identified  the  top-level  functional  requirement  of  a  FUWS  as  Naval  Tactical  Task 
(NTA)  1.4,  Conduct  Counter-mobility.  When  decomposing  “Conduct  FUWS  operations” 
in  light  of  this  tie  to  counter-mobility,  the  team  generated  an  alternative  top-level 
functional  architecture  (Figure  9)  focused  on  describing  the  functions  required  to  conduct 
counter-mobility.  In  this  decomposition,  the  FUWS  collects  information  from  the 
environment  and  threat,  the  uncontrollable  inputs  of  the  functional  context.  This 
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information  then  feeds  the  execution  of  internal  command  and  control  functions  as  well 
as  possible  coordination  with  external  systems.  The  rule  sets  that  drive  these  command, 
control  and  communication  functions  are  based  on  the  controllable  inputs  in  functional 
context.  When  the  predetermined  engagement  logic  directs,  the  FUWS  engages  a  threat 
to  limit  its  mobility  on  or  below  the  sea.  The  loops  in  this  decomposition  show  the  highly 
iterative  nature  of  the  system’s  operational  activities.  Because  it  focused  on  decomposing 
the  military  task  to  demonstrate  the  system’s  functionality,  the  team  adopted  this 
alternative  functional  decomposition  for  use  in  MFSA  modeling. 


efffad  Conduct  Countermobility  J 
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Figure  9.  FUWS  Conduct  Counter-mobility  EFFBD 


3.  Functional  Allocation 

With  the  modified  understanding  of  the  FUWS  functional  decomposition,  the 
Mental  Focus  team  proceeded  to  examine  the  functional  allocation  to  component 
subsystems  at  the  top-level  architecture.  These  subsystems  and  their  interactions  will 
form  the  basis  for  modeling  in  MFSA. 

As  seen  in  Figure  10,  the  SEA17B  project  identified  three  top-level  subsystems. 
These  subsystems  can  be  mapped  to  the  functions  identified  in  Figure  9  and  were 
accepted  by  the  Mental  Focus  team  as  an  appropriate  physical  decomposition  of  a  generic 
FUWS,  suitable  for  modeling  in  MFSA. 
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Figure  10.  FUWS  High  Level  Decomposition 


In  order  to  understand  the  functional  limitations  of  each  subsystem,  the  SEA17B 
cohort  decomposed  these  subsystems  into  technologies  based  on  the  physical  phenomena 
exploited  in  various  solution  sets.  The  Mental  Focus  team  began  with  the  SEA17B 
decomposition,  but  winnowed  down  the  list  of  technologies  considered  based  on  those 
with  to  the  greatest  congruence  with  mission  requirements  and  highest  technological 
readiness.  The  challenges  and  opportunities  associated  with  each  of  these  technologies 
must  be  considered  by  MFSA 

a.  Sensors 

The  FUWS  sensors  must  be  capable  of  collecting  information  from  the  threat 
transmitted  through  the  undersea  environment.  These  sensors  must  leverage  phenomena 
that  could  be  used  to  detect  and  classify  the  presence  of  a  threat.  The  Mental  Focus  team 
assessed  that  acoustic  (both  passive  and  active),  magnetic,  pressure  and  seismic  sensors 
(Figure  11)  provided  the  most  mature  technologies  and  most  realistic  sensor  sets  for  use 
the  FUWS.  As  such,  their  employment  in  sensor  network(s)  must  be  capable  of  modeling 
by  MFSA.  The  team  considered  the  use  of  optical  sensors  but  considered  the  ranges 
associated  with  the  transmission  of  photic  energy  through  seawater  as  limiting  and 
excluded  optical  sensors  from  the  MFSA  requirement. 
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bdd  Sensor  [After  SEA17B  2D  11  Figure  3.17] 
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Figure  11.  Possible  FUWS  Sensor  Technologies  (adapted  from  SEA17B 

2011) 


b.  Communicators 

The  FUWS  communicators  must  be  capable  of  transmitting  data  through  the 
undersea  environment  from  the  sensors  to  the  weapons.  Additionally,  because  the 
command  and  control  functions  used  to  make  engagement  decisions  must  happen 
between  the  sensor  and  weapon,  these  functions  were  assigned  to  the  communicators. 
The  limiting  technological  challenge  of  transmitting  data  through  the  undersea 
environment  was  used  to  categorize  the  possible  communicator  technologies  (Figure  12). 

The  Mental  Focus  team  assessed  that  acoustic  (digital  and  analogue)  and  radio 
buoy  (line-of-sight  and  satellite  relay)  communications  provided  the  most  mature 
technologies  and  realistic  communicators.  The  team  also  considered  the  possible 
introduction  of  future  laser  communications  as  a  possible  solution  based  on  Defense 
Advanced  Research  Projects  Agency  (DARPA)  Tactical  Relay  Information  Network 
(TRITON)  efforts  in  developing  undersea  blue  laser  communications.  Finally,  the  team 
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included  connected  communications  (fiber-optic  and  conductive  wire)  as  a  possible 
solution,  particularly  in  protective  mining  scenarios.  The  team  excluded  physical 
messengers  from  consideration  based  on  the  speed  of  communications  required  to  engage 
moving  targets  and  the  energy  required  for  supersonic  undersea  transit. 


bdd  Communicator  [After  SEA17B  2011  Figure  3.17] 
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Figure  12.  Possible  FUWS  Communicator  Technologies  (adapted  from 

SEA17B  2011) 


c.  Weapons 

FUWS  weapons  must  be  capable  of  intercepting  and  limiting  the  mobility  of  an 
identified  threat,  using  information  passed  by  the  communicators.  Possible  weapon 
categories  broadly  include  kinetic  and  non-kinetic.  Kinetic  weapons  rely  on  physical 
force,  normally  associated  with  an  explosive  blast,  to  damage  the  target.  These  weapons 

26 


include  both  fixed  (similar  to  current  mines)  and  mobile  (similar  to  current  torpedoes) 
explosive  charges.  The  alternative  kinetic  weapons  in  the  SEA17B  decomposition  are 
indistinguishable  from  these  broad  categories.  For  example,  the  embedded  warhead  in  an 
undersea  vehicle  is  effectively  a  slow  speed  torpedo.  Non-kinetic  options,  identified  as 
soft  kill  weapons  in  the  SEA17B  decomposition,  would  include  alternative  mechanisms, 
such  as  use  of  the  electro-magnetic  spectrum,  to  disable  threats  and  counter  their 
movement  through  the  mined  area.  The  revised  categorical  decomposition  of  possible 
weapon  classifications  is  shown  in  Figure  13. 


bdd  Weapon  [After  SEA17B  2011  Figure  3. 17] 
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Figure  13.  Possible  FUWS  Weapon  Classifications  (adapted  from  SEA17B 

2011) 
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c. 


EXISTING  CAPABILITY  REVIEW 


The  Mental  Focus  team  leveraged  William  Bard’s  NPS  thesis,  “Naval  Minefield 
Modeling  and  Simulation:  An  Examination  of  General  Analytical  Minefield  Evaluation 
Tool  (GAMET)  and  other  Minefield  Models,”  as  an  analysis  of  alternatives  of  current 
minefield  simulation  capabilities.  Bard  concludes  that  GAMET  provides  the  most 
effective  and  capable  system  currently  available  for  future  mining  concepts  such  as 
FUWS  (2013,  53-54).  The  team  accepted  this  conclusion,  limiting  the  team’s  review  of 
existing  capability  to  the  GAMET  system. 

GAMET  provides  “an  object-oriented,  event-driven  simulation  used  in  the 
evaluation  of  minefield  effectiveness,  system  performance  trade-offs  and  transitor 
vulnerability”  (Belton  2015,  2).  It  was  initially  developed  in  1998,  predating  the 
development  of  the  AUWS  concept.  While  subsequent  GAMET  version  releases  have 
incorporated  some  ability  to  simulate  a  “networked  field  of  cooperative  sensor,  relays  and 
remote  weapons”  (Belton  2015,  4),  the  capability  provided  by  GAMET  remains  limited 
and  incomplete.  MFSA  will  address  these  gaps.  Additionally,  because  of  GAMET’s 
established  pedigree,  the  team  identified  a  number  of  GAMET  system  components  that 
could  be  incorporated  in  an  evolutionary  development  of  MFSA.  Chapter  V.D  provides 
more  details. 


1.  Output  Limitations 

Perhaps  its  most  significant  limitation  is  the  paucity  of  outputs  generated  by 
GAMET,  specifically  the  limited  types  of  minefield  MOPs.  GAMET  is  capable  of 
predicting  two  types  of  MOPs  for  a  given  scenario  simulation,  the  simple  initial  threat 
(SIT)  and  the  expected  casualties  (EC).  The  SIT  is  an  estimate  of  the  threat  presented  by 
the  minefield  to  the  first  transiting  target  vessel,  expressed  as  the  probability  that  the 
threat  is  prevented  from  transiting  the  minefield.  The  EC  is  the  expected  value  (mean) 
number  of  target  vessels  prevented  from  transiting  the  minefield  in  a  given  scenario 
(Belton  2015,  16). 

While  these  simple  MOEs  may  be  adequate  for  comparison  of  legacy,  explode-in- 


place,  minefield  configurations  they  fail  to  adequately  highlight  the  potential  emergent 

28 


capabilities  of  a  networked  and  mobile  FUWS  architecture.  For  example,  the  decay 
profile  of  the  minefield  threat  presented  to  the  nth  target  vessel  could  vary  dramatically 
between  a  legacy  minefield  and  various  FUWS  architectures.  Without  understanding  this 
risk  profile,  the  system  developers  will  not  understand  the  impacts  of  trade  space  in  a 
FUWS  architecture  and  operational  planners  will  not  properly  optimize  the  employment 
of  FUWS  capabilities. 

This  lack  of  a  more  robust  set  of  MOEs  is  indicative  of  an  enterprise-wide 
shortfall  in  doctrinal  minefield  MOEs.  Given  the  demonstrated  lack  of  attention  to 
mining  capability  development,  this  may  not  be  particularly  surprising.  However,  with 
the  current  resurgence  of  interest  in  mining  capabilities  and  development  work  on 
AUWS,  relevant  MOEs  for  distributed,  networked  minefields  must  be  developed  to 
support  comparative  analysis.  Simulation  systems  must  be  capable  of  predicting  these 
MOEs  to  support  optimal  system  development  and  employment.  To  support  this  effort 
and  define  relevant  MFSA  output  requirements,  the  project  team  developed  a  number  of 
proposed  FUWS  MOEs  (see  Chapter  III.C.3).  MFSA  must  be  capable  of  outputting  new 
MOEs  identified  as  relevant  in  the  development  and  employment  of  FUWS  architectures. 

2.  Architecture  Limitations 

The  upgrades  to  GAMET  that  enable  simulation  of  FUWS  only  allow  for  limited 
FUWS  architectures.  Specifically,  the  upgrades  were  biased  toward  modeling  sensors  and 
communicators  and  less  focused  on  modeling  enhanced  weapon  components.  For 
instance,  while  GAMET  allows  the  system  user  to  mix  different  communicators  (modem 
types)  in  a  scenario,  the  user  may  only  use  a  single  weapon  type  in  the  scenario  and  the 
system  does  not  simulate  different  characteristics  associated  with  various  weapon  types 
(Belton  2015,  7).  Additionally,  GAMET  does  not  consider  many  of  the  probabilities 
involved  in  the  effective  engagement  of  the  target  by  a  weapon.  Instead  it  uses  a  single 
probability,  probability  of  fire  (PF),  to  determine  the  outcome  of  an  engagement.  While 
this  simplistic  approach  may  have  been  effective  for  an  explode-in-place  architecture,  it 
leaves  significant  gaps  in  the  ability  to  understand  and  compare  the  performance  of 
various  weapons,  including  mixes  of  weapons,  and  targeting  logics  in  an  advanced 
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FUWS.  MFSA  must  be  capable  of  modeling  multiple  weapon  types  and  configurations  of 
mixed  weapons  types  with  a  number  of  targeting  logics. 

3.  Scenario  Limitations 

GAMET  employs  a  simple,  one-at-a-time  transit  of  target  vessels  in  the 
simulation.  While  this  may  be  adequate  for  legacy  minefields,  it  does  not  provide  users 
with  an  understanding  of  the  complicating  impacts  on  targeting  logic  associated  with  the 
presence  of  multiple  target  vessels.  Simply  put,  when  evaluating  a  mobile  weapon  such 
as  a  torpedo  it  is  important  to  consider  other  vessels  in  the  same  vicinity.  MFSA  must  be 
capable  of  modeling  scenarios  in  which  multiple  target  vessels  are  simultaneously 
transiting  the  minefield. 

4.  Usability  Limitations 

Finally,  the  current  version  of  GAMET  is  a  complex  software  tool  suitable  for  use 
by  trained  analysts,  but  not  necessarily  by  operational  planners.  In  fact,  the  “GAMET 
User’s  Guide”  directs  users  to  partner  or  consult  with  GAMET  developers  when  building 
a  scenario.  The  GAMET  architecture  requires  users  to  provide  formatted  parameter  data 
in  at  least  nine  different  input  files.  The  data  input  formats  are  so  cumbersome,  the  User’s 
Guide  recommends  copying  and  editing  sample  sets  of  data  to  minimize  input  errors 
(Belton  2015,  1-3).  As  a  result,  users  trained  in  a  NPS  project  criticized  the  cumbersome 
user  interface  (Bard  2013,  22).  MFSA  must  be  capable  of  broad  acceptance  by  the 
operational  planning  and  program  analyst  user  communities  by  providing  a  flexible  and 
intuitive  user  interface. 
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III.  REQUIREMENT  IDENTIFICATION 


In  our  approach,  “requirements”  and  “interface  definitions”  are  treated  in 
the  same  way  using  common  semantics.  This  is  because  the  two  are 
intimately  linked  and  quite  often  viewed  as  the  same  because  they  both 
represent  binding  contracts.  Requirements  are  a  contract  between  a 
developer  and  those  stakeholders  that  interact  with  the  developer. 
Interfaces  enable  communication  and  interaction  between  elements  within 
a  system  as  well  as  between  the  system  and  its  environment.  In  the  interest 
of  simplification,  we  employ  the  term  “requirements”  from  this  point  on  as 
short  for  both  requirements  and  interface  definitions.  (Madni  and  Sievers 
2014,  43) 

This  chapter  presents  the  Mental  Focus  team’s  approach  to  requirement  discovery 
by  identifying  the  MFSA  functional  interfaces  and  articulating  the  information  exchanges 
at  these  interfaces.  Using  a  discovery  process  of  UML  use  case  identification  and 
elaboration  (Pressman  2015,  173),  the  team  further  decomposed  these  requirements.  This 
process  of  information  exchanges  informed  the  development  of  the  system  architecture 
requirements  described  in  future  sections. 

A.  USER  CLASSES 

The  team  began  by  analyzing  the  active  stakeholders  (Chapter  II,  Table  4)  and 
their  associated  information  needs.  The  team  identified  four  classes  of  users  that  would 
interact  with  the  system  and  require  system  interfaces.  Shown  in  Figure  14,  these  user 
classes  are  grouped  into  two  principal  categories:  customers  of  MFSA  outputs  and 
providers  of  MFSA  inputs.  These  different  perspectives  on  the  MFSA  and  the  users’ 
interactions  with  it  assisted  the  team  in  the  development  of  a  flexible  architecture  that 
addressed  multiple  stakeholder  needs. 

1.  Program  Analyst 

The  Program  Analyst  user  class  includes  both  the  acquisition  professional, 
concerned  with  cost,  schedule,  and  performance  tradeoffs  of  various  available 
technologies,  and  the  system  development  engineer,  concerned  with  how  different 
component  characteristics  affect  overall  system  performance.  For  example,  an  analyst 
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may  want  to  quickly  perform  a  parametric  study  to  see  which  variables  produce  the 
optimal  results  or  the  analyst  may  want  to  run  a  series  of  more  detailed  scenarios  to 
supplement  and  mitigate  the  expense  of  live-fire  testing.  The  program  analyst  will  likely 
be  satisfied  to  use  generic,  or  representative  approximations  of  operational  environments 
with  detailed  descriptions  of  the  weapon  system  and  threat.  Ultimately  the  analyst  is 
interested  in  “what  is  possible  in  the  future”  with  a  FUWS  and  “what  is  the  optimal 
allocation  of  resources”  to  support  the  procurement  of  a  future  FUWS  system  acquisition 
or  upgrade.  The  team  envisions  that  this  class  of  user  encompasses  users  from  NAVSEA, 
including  the  component  program  offices  and  warfare  development  centers. 
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Figure  14.  User  Class  Diagram 


2.  Operational  Planner 

The  second  intended  user  class  consists  of  Operational  Planners,  and  represents 
the  warfighter  applicability  of  MFSA.  These  users  are  planning  and  providing  military 
capabilities  to  operational  commanders,  within  defined  mission  constraints.  They  are 
interested  is  ensuring  that  assigned  resources  and  available  FUWS  components  are 
arranged  to  provide  the  required  capability.  These  users  will  likely  desire  to  use  the  best 
environmental  data  available  to  predict  performance  in  a  specific  tactical  scenario.  While 
the  operational  planner  may  coordinate  with  developers  in  the  refinement  of  future 
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FUWS  requirements,  the  operational  planner  is  principally  concerned  with  “what  is 
possible  with  FUWS  assets  currently  available.” 

The  design  approach  proposed  by  the  Mental  Focus  team  assumes  the  operational 
planner  has  an  informed  technical  background  and  is  familiar  with  both  the  employment 
of  undersea  weapon  systems  and  the  dynamics  of  the  undersea  environment.  The  team 
envisions  that  this  class  of  user  encompasses  users  from  operational  commands,  such  as 
Joint  Force  Maritime  Component  Commanders,  and  reach-back  planning  support 
commands  such  as  the  Naval  Surface  and  Mine  Warfighting  Development  Center 
(SMWDC). 


3.  System  Administrator 

The  team  added  a  third  user  class,  the  system  administrators,  whose  role  is 
providing  and  maintaining  the  required  input  information.  While  in  practice  a  system 
developer  or  operational  planner  may  also  be  a  system  administrator,  the  team 
determined  that  establishing  a  separate  role  for  the  responsibility  of  maintaining  input 
data  libraries  would  simplify  the  behavioral  modeling  of  MFSA  interactions  with  users.  It 
would  also  assist  the  team  in  subsequent  analysis  and  discovery  of  sustainment  and 
maintenance  requirements. 

The  system  administrator  role  would  also  include  system  maintainers  and  the  in- 
service  engineering  agent  (ISEA),  who  maintains  configuration  control  and  validation 
authority  over  the  data  being  supplied  to  the  MFSA  system. 

4.  Authoritative  Databases 

Finally,  the  Mental  Focus  team  recognized  the  need  for  MFSA  to  pull  data  from 
authoritative  databases  of  information,  either  via  the  system  developer  or  via  direct 
interface.  Databases  of  environmental,  threat,  weapon  and  sensor  data  exist  and  are 
maintained  by  numerous  offices  in  numerous  formats.  It  would  be  impractical  for  MFSA 
to  compile  and  maintain  a  single  central  database  from  all  these  various  sources,  thus 
individual  MFSA  installations  would  need  to  be  capable  of  tracing  the  pedigree  of  data 
input  streams  in  order  to  support  user  confidence  in  simulation  outputs.  In  an  ideal 
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architecture,  MFSA  would  be  capable  of  interfacing  directly  with  authoritative  databases 
to  ensure  the  most  current  and  accurate  information  is  used  in  the  simulation. 

B.  MFSA  INPUTS  AND  OUTPUTS 

The  Mental  Focus  team  next  analyzed  the  customer  stakeholder  concerns 
(Chapter  II,  Table  4)  and  associated  information  needs  to  establish  high-level  groupings 
of  system  output  and  input  requirements.  As  seen  in  Figure  15,  and  further  articulated  in 
Table  6,  the  team  identified  two  top-level  groupings  of  functional  outputs  and  four 
groupings  of  inputs. 


INPUT  SYSTEM  OUTPUT 


Figure  15.  MFSA  Functional  Inputs  and  Outputs 


Next,  the  team  translated  these  concerns  and  needs  into  the  high  level  MFSA 
output  requirements  provided  in  Table  6  (Req.2.1  and  Req.2.2).  Starting  from  these  high- 
level  functional  output  requirements,  the  team  derived  categories  of  data  inputs  required 
to  calculate  the  required  outputs.  In  addition  to  data  about  the  FUWS,  the  team  identified 
a  need  for  information  about  the  target,  the  environment,  and  the  goals  of  the  operational 
commander  as  MFSA  inputs.  These  categories  of  data  are  summarized  in  the  high  level 
MFSA  input  requirements  in  Table  6  (Req.1.1  thru  Req.1.4). 
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Table  6.  MFSA  Functional  Input-Output  Requirements 


Requirement 

Threshold 

Objective 

Req.1.1 

MFSA  shall  simulate  future  weapon 
systems  by  using  data  representing  the 
performance  of  undersea  sensors,  kinetic 
and  non-kinetic  effectors,  associated 
communicators  and  fire  control  and 
targeting  logic 

Simulates  existing 
technologies 

Simulates 
technologies  at  or 
above  TRL  5 

Req.1.2 

MFSA  shall  simulate  exchange  of  EMI 
in  the  undersea  environment  by  using 
data  describing  the  environmental 
conditions  of  the  area  of  concern 

User  input 
environment  data 

External  database 
input 

Req.1.3 

MFSA  shall  simulate  targets  operating 
in  the  area  of  concern  by  using  data  on 
target  physical  parameters,  signal 
sources  and  operating  characteristics 

Simulates  surfaced 
military  vessels 

Simulates  surfaced 
or  submerged 
military  vessels 
and  neutral  vessels 

Req.1.4 

MFSA  shall  simulate  various  mission 
objectives  defined  by  the  operational 
commander 

Selected  friendly 
and  enemy  mission 
sets 

User  designed 
friendly  and 
enemy  missions 

Req.2.1 

MFSA  shall  calculate  and  predict 
measures  of  effectiveness  and 
performance  obtained  in  a  scenario 

Current  doctrinal 
MIW  measures  of 
effectiveness  and 
performance 

Customizable 
measures  of 
effectiveness  and 
performance 

Req.2.2 

MFSA  shall  calculate  and  propose  the 
number,  type  and  placement  of  sensors, 
effectors  and/or  command  and  control 
(C2)  nodes  required  to  achieve  either  a 
desired  effectiveness  or  the  optimal 
effectiveness  within  a  resource  limit 

Optimal 

configuration 

proposed 

Efficient  frontier 
of  cost 
effectiveness 
proposed 
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In  each  case  the  proposed  threshold  and  objective  levels  of  performance  describe 
the  team’s  analysis  of  the  stakeholder’s  needs  and  wants.  Understanding  the  MFSA 
output  capabilities  are  a  function  of  the  inputs  captured,  the  team  focused  its  energy  on 
decomposing  the  input  requirements  in  Table  6  using  use  cases  and  scenario  narratives. 

C.  COMMON  USE  CASES 

The  identified  input  and  output  requirements  were  validated  using  Unified 
Modeling  Language  (UML)  use  case.  Figure  16  shows  the  primary  actors  interfacing 
with  the  system  and  the  use  cases  (Pressman  2015,  875)  that  describe  the  intended  use  of 
the  proposed  MFSA  system,  guide  the  development  of  requirements  models,  and  support 
requirement  discovery. 


Figure  16.  MFSA  Use  Cases 


Note  the  parallel  paths  and  overlaps  shown  in  Figure  16  between  the  FUWS 
program  analyst  and  operational  planner  user  experiences.  While  both  of  these  classes  of 
users  are  concerned  with  using  MFSA  to  obtain  decision  support  information,  they  have 
slightly  different  information  needs.  The  analyst  desires  to  understand  the  trade  space 
between  various  FUWS  technical  parameters;  the  operational  planner  requires  the  ability 
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to  assemble  and  predict  the  performance  of  a  specific  configuration  of  FUWS 
components  to  provide  a  military  capability. 

1.  Use  Case:  Configure  Scenario 

In  this  use  case,  the  user  logs  into  MFSA  with  the  tools  and  options  configured  for 
the  anticipated  set  of  tasks  performed  by  that  user.  After  logging  in,  the  user  first 
configures  a  scenario.  To  do  this,  the  user  may  either  create  a  new  scenario  or  to  select  a 
previously  scenario  from  a  database  and  continue  analysis.  When  selecting  a  new 
scenario,  the  user  defines  the  environment  in  which  the  FUWS  will  operate  (Req.1.2),  the 
target  the  FUWS  will  counter  (Req.1.3),  and  the  operational  commander’s  mission  or 
objective  (Req.1.4). 

To  define  the  environment,  the  user  is  presented  with  a  choice:  create  a  user- 
defined  environment,  import  environmental  data  from  an  external  database  or  library,  or 
load  an  existing  environment  from  a  database  of  previously  saved  work.  When 
developing  a  user-defined  scenario,  MFSA  will  provide  the  user  with  an  indication  of  the 
model  maturity  level  as  well  as  identify  the  minimum  required  input  parameters.  The 
team  anticipates  the  minimum  environmental  requirements  include  geographic 
boundaries  and  water  depth  data.  Table  7  provides  a  decomposition  of  Req.1.2  into  a  list 
of  potential  environmental  parameters  that  may  be  utilized  by  MFSA  to  provide  higher 
levels  of  simulation  resolution.  Appendix  C  provides  additional  details  on  the  functional 
purpose  of  these  parameters  within  the  MFSA  simulation  process. 

As  seen  in  Table  7,  the  team  envisioned  three  levels  of  simulation  resolution 
(basic,  intermediate,  and  advanced),  each  requiring  additional  levels  of  input  data  and 
providing  more  detailed  analysis.  These  resolutions  provide  a  relative  scale  of  MFSA 
analysis  detail  available  based  on  the  available  input  data  and  can  assist  the  user  in 
determining  the  input  requirements  required  to  achieve  higher  levels  of  model  fidelity. 
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Table  7.  MFSA  Environmental  Input  Parameters  (Req.  1 .2) 


Environmental  Parameter 

Basic 

Inter 

Advance 

Geographic  boundaries 

X 

X 

X 

Water  depth 

X 

Bathymetric  profile 

X 

X 

Sound  velocity  profile  (SVP) 

X 

Current 

X 

X 

Ambient  noise  level  (AN) 

X 

X 

Ambient  noise  frequency  range 

X 

Seismic  background  noise 

X 

Bottom  type  /  Bottom  loss 

X 

X 

Fixed  obstacles  (e.g.,  oil  rig) 

X 

X 

Probabilistic  obstacles 

X 

Following  the  definition  of  the  environmental  parameters,  the  user  is  prompted  to 
define  the  target.  As  before,  the  user  is  presented  with  a  choice:  create  a  user-defined 
target,  import  target  data  from  an  external  database  or  library,  or  load  an  existing  target 
from  a  database  of  previously  saved  work.  Again,  MFSA  will  provide  the  user  with  an 
indication  of  the  model  maturity  level  and  the  minimum  required  input  parameters.  The 
team  anticipates  the  minimum  target  data  requirements  include  target  course  and  speed, 
target  acoustic  and  magnetic  signatures,  target  mission,  and  target  sequence  number. 
Table  8  provides  a  decomposition  of  Req.  1.3  into  a  list  of  potential  target  parameters  that 
may  be  utilized  by  MFSA  to  provide  higher  levels  of  simulation  resolution. 

The  final  step  in  setting  up  a  scenario  is  defining  the  operational  commander’s 
intended  mission ,  including  objectives,  restraints  and  constraints.  As  before,  the  user  is 
presented  with  options:  create  a  user-defined  mission  or  load  an  existing  mission  from  a 
database  of  previously  saved  work.  Table  9  provides  a  decomposition  of  Req.  1.4  into  a 
list  of  potential  mission  parameters  that  may  be  utilized  by  MFSA  at  various  levels  of 
simulation  complexity. 
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Table  8.  MFSA  Target  Input  Parameters  (Req.  1.3) 


Target  Vessel  Parameter 

Basic 

Inter 

Advance 

Number  (1  to  n) 

X 

X 

X 

Course 

X 

X 

X 

Speed 

X 

X 

X 

Max  speed 

X 

X 

Class/type 

X 

X 

Target  mission 

X 

X 

X 

Displacement 

X 

X 

Length 

X 

X 

Width  (Beam) 

X 

X 

Draft 

X 

X 

Damage  susceptibility 

X 

X 

X 

Magnetic  signature 

X 

X 

Acoustic  signature 

X 

X 

Ship  countermeasures 

X 

Maneuvering  tactics 

X 

X 

Countermeasures  tactics 

X 

Mine  hunting  mission 

X 

Mine  sweeping  mission 

X 

Hull  material 

X 

X 

Target  priority 

X 

X 

Table  9.  MFSA  Mission  Input  Parameters  (Req.  1 .4) 


Mission  Parameter 

Basic 

Inter 

Advance 

Limited  Rules  of  Engagement 

X 

Human  “in  loop”  required 

X 

Target  discrimination  required 

X 

X 

2.  Use  Case:  Configure  FUWS 

In  this  use  case,  the  user  has  previously  logged  on  and  configured  a  scenario.  The 
user  then  configures  the  FUWS.  The  user  may  either  load  existing  configuration  or  create 
a  new  configuration.  When  selecting  a  new  scenario,  the  user  defines  the  environment  in 
which  the  FUWS  will  operate,  the  target  it  will  counter,  and  the  operational 
commander’s  mission  or  objective  (Table  10). 

After  the  user  has  constructed  the  scenario  then  next  step  is  the  construction  of  the 
minefield,  either  by  manually  placing  the  assets  into  the  environment,  or  by  using  an 
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automation  function  which  will  apply  “rules  of  thumb”  to  generate  a  configuration  to 
meet  the  intended  performance  objectives.  The  user  will  build  the  FUWS  architecture 
based  on  sensors,  communication  technologies,  weapons  and  command  logic  from  a 
database  within  MFSA.  One  of  the  features  unique  to  the  analyst  role  is  the  ability  to 
define  new  components  and/or  modify  existing  components  and  add  those  to  the  MFSA 
database.  This  will  allow  the  developer  to  perform  system  analysis  to  inform  technology 
investments  and  priorities. 


Table  10.  MFSA  FUWS  Input  Parameters  (Req.  1.1) 


FUWS  Parameters 

Basic 

Inter 

Advance 

Sensors 

Number  (1  to  n) 

X 

X 

X 

Sensor  Type 

X 

X 

X 

Position 

X 

X 

X 

Probability  Detect  v  Range 

X 

X 

X 

Bearing  Accuracy 

X 

X 

Reliability 

X 

X 

Timing 

X 

Endurance  /  Power  Usage 

X 

Communicators 

Range 

X 

X 

X 

Data  rate 

X 

X 

Latency 

X 

X 

Reliability 

X 

X 

Endurance  /  Power  Usage 

X 

Weapons 

Number  (1  to  n) 

X 

X 

X 

Weapon  Type 

X 

X 

X 

Position 

X 

X 

X 

UUV  Weapon  Batteries 

X 

X 

X 

Intercept  Speed 

X 

X 

X 

Search  Speed 

X 

X 

X 

Explosive  power 

X 

X 

X 

Range 

X 

X 

X 

Endurance 

X 

X 

Reliability 

X 

X 

Weapon  Search  Pattern 

X 

Targeting  Logic 

X 

X 

X 
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3. 


Use  Case:  Simulate  Mission 


Upon  successfully  populating  the  model  a  “run  simulation”  button  will  become 
available.  The  user  will  have  the  option  to  run  a  single  simulation  or  run  a  series  of 
simulations  for  Monte  Carlo  analysis.  An  option  to  run  the  simulation  graphically  will  be 
available  to  help  the  developer  visualize  how  the  system  is  performing  in  real  time.  This 
feature  will  help  with  tailoring  the  configuration  or  troubleshooting  a  simulation  that  does 
not  produce  the  desired  results.  After  the  simulation  completes  the  selected  number  of 
runs,  a  summary  of  the  data  will  be  provided  on  the  screen,  along  with  the  selected 
measures  of  performance  of  Table  11. 


Table  1 1 .  MFSA  Predicted  FUWS  Performance  Outputs  (Req.2. 1) 


MOP/MOE  Outputs 

Basic 

Inter 

Advance 

Simple  initial  threat  (SIT) 

X 

X 

X 

Threat  profile  (1  to  n) 

X 

X 

X 

Expected  time  to  engagement 

X 

X 

Expected  casualties 

X 

X 

X 

Resistance  to  channeling 

X 

X 

X 

Probability  of  detection  (Pd) 

X 

X 

X 

Probability  of  classification  (Pc) 

X 

X 

Probability  of  engagement  (PF) 

X 

Probability  of  kill  (Pk) 

X 

X 

System  failures 

X 

X 

Fratricide  risk 

X 

Expected  false  engagements 

X 

Expected  unused  ordinance 

X 

4.  Use  Case:  Generate  Apportionment  Request 

This  use  case  assumes  the  completion  of  the  “configure  scenario”  use  case  and  is 
provided  as  an  alternative  to  the  “configure  FUWS”  use  case.  It  allows  the  user  to 
identify  required  operational  counter-mobility  effects  as  FUWS  measures  of  performance 
and  resource  constraints.  When  sufficient  data  is  available,  MFSA  will  allow  the  user  to 
“generate  system  requirements”  and  will  provide  the  user  with  an  asset  configuration  (or 
configurations)  that  provides  the  desired  level  of  performance  as  seen  in  Table  12.  This 
planning  function  provides  the  predictive  optimization  feature  of  MFSA  and  generates 
the  outputs  required  to  address  Req.2. 2  of  Table  6. 
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Table  12.  MFSA  Proposed  Configuration  Outputs  (Req.2.2) 


FUWS  Configuration 

Basic 

Inter 

Advance 

Optimal  configuration  of  single  asset 
classes  proposed 

X 

X 

X 

Optimal  configuration  of  mixed  asset 
classes  proposed 

X 

X 

Efficient  frontier  of  cost  effectiveness 

X 
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IV.  NON  FUNCTIONAL  REQUIREMENTS 


Non-functional  requirements  provide  a  description  of  a  system’s  required 
characteristics  that  are  not  directly  traceable  to  the  system’s  raison  d’etre.  While 
necessary  to  the  accomplishment  of  the  system’s  mission,  they  are  a  consequence  of  the 
system’s  existence.  As  reflected  in  the  terminology  of  Stellman  and  Green  who  refer  to 
them  with  such  terms  as  “constraints,”  “quality  attributes,”  and  “non-behavioral 
requirements”  (2005,  113);  non-functional  requirements  are  often  qualitative.  However, 
as  seen  in  Figure  17,  these  qualitative  concepts  can  often  be  mapped  to  proxy, 
quantitative  metrics. 


Figure  17.  Non-Functional  Requirements  to  Metrics  (source:  Budgen  1994) 

This  chapter  describes  the  non-functional  requirements  most  relevant  to  MFSA 
development  and  describes  a  process  by  which  these  traits  should  be  implemented.  The 
team  identified  key  considerations  and  best  practices,  which  will  lead  to  a  quality  MFSA 
product  and  to  high  end-user  satisfaction.  The  non-functional  requirements  were  grouped 
in  two  broad  categories: 

•  operational  requirements  which  focus  on  the  user  experience 

•  maintainability  and  supportability  which  focus  on  life  cycle  logistic  support 
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A.  OPERATIONAL  REQUIREMENTS 
1.  Usability 

If  a  product  is  to  be  successful,  it  must  exhibit  good  usability  —  a 
qualitative  measure  of  the  ease  and  efficiency  with  which  a  human  can 
employ  the  functions  and  features  offered  (Pressman  2015,  3 17) 

Usability,  by  definition,  is  subjective  based  on  the  user’s  experience  interacting 
with  the  software  and  thus  requires  user  interaction  early  in  the  system  life  cycle  to 
design  and  evaluate.  This  can  be  done  using  iterative  approaches  such  as  the  spiral 
development  model  shown  in  Figure  18  (Pressman  2015,  323).  To  support  this  iterative 
approach,  the  team  developed  a  prototype  simulation  tool,  described  in  Chapter  VI,  that 
provided  an  interface  for  user  validation.  Additionally,  based  on  feedback  from  users10 
and  the  design  principles  discussed  in  this  section,  the  team  developed  a  second  interface 
mockup,  discussed  in  Appendix  I,  which  provides  a  vision  of  a  fully  operational  MFSA 
graphical  user  interface. 


lntnrfnro  vnlidntion 


Interfnrf*  onnlvii*;  and  modeling 


Figure  18.  Spiral  Process  for  Interface  Design  (source:  Pressman  2015,  324) 

Tognozzi  provides  a  set  of  design  principles  (via  Pressman  2015,  338-339), 
which  can  support  development  of  software  system  usability.  The  team  considered  these 


10  Team  members  role-played  as  stakeholder  users  when  interacting  with  the  prototype  to  accelerate 
the  user  feedback  timeline  within  project  constraints. 
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principles  and  selected  the  following  six  principles  for  articulating  MFSA  usability 
requirements. 

1 .  Flexibility. 

MFSA  shall  support  flexible  user  input  modes.  As  described  in  Chapter  III, 
MFSA  requires  numerous  user  inputs  (Req  1)  to  configure  the  FUWS  components, 
construct  the  simulation  environment,  and  run  the  simulation.  In  order  to  make  the 
process  less  time  consuming  and  more  user-friendly,  MFSA  should  support  multiple 
input  modes  wherever  practical  to  increase  flexibility.  As  an  example,  the  user  may  select 
the  number  of  weapons  in  a  given  minefield  by  either  dragging  a  slide  bar  to  a  desired 
number  or  by  typing  in  the  number.  Having  the  ability  to  select  from  multiple  input 
modes  allows  a  user  to  choose  a  comfortable  method. 

2.  Metaphors. 

MFSA  shall  use  a  visual  layout  based  on  naval  tactical  systems.  This  technique 
provides  the  user  with  familiar  visual  cues  to  help  guide  the  interactive  process  and 
understand  the  components  in  the  simulation.  When  constructing  the  environmental 
conditions  and  boundaries  of  a  minefield,  MFSA  will  display  a  graphical  representation 
of  the  area  with  bathymetry  visualized  using  color  gradients.  FUWS  system  components 
should  be  represented  with  icons  consistent  with  Common  Warfighting  Symbology 
(MIL-STD-2525B)  whenever  possible.  The  expected  user  community  will  be  familiar 
with  and  comfortable  with  these  metaphors  (McFadden  et  al.  2008,  iii),  which  will  help 
enable  widespread  adoption. 

3.  Consistency. 

MFSA  shall  provide  a  user  interface  consistent  with  the  Global  Command  and 
Control  System,  Maritime  (GCCS-M)  interface.  Unless  there  is  a  compelling  reason  for 
change,  using  patterns  which  are  familiar  to  the  user  enhances  the  user  experience.  Using 
the  GCCS-M  interface  pattern  will  provide  a  user  experience  likely  to  be  familiar  to 
operational  users  of  the  system  and  decision  makers.  This  will  also  support  integration 
with  other  warfare  area  planning  tools. 
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4.  Human  Interface  Objects. 

MFSA  shall  use  existing  object  libraries  to  provide  user  interface  objects. 
Implementing  familiar  design  patterns,  such  as  drop  down  menus,  and  sliders,  will  help 
make  MFSA  more  intuitive  to  use,  reduce  learning  time,  and  improve  efficiency. 

5.  Controlled  Autonomy 

MFSA  shall  guide  the  user  through  the  simulation  setup  and  execution.  The  user 
must  be  presented  with  an  intuitive  path  to  constructing  a  functional  model  based  on  the 
inputs  the  user  has  already  provided.  Additionally,  since  the  accuracy  and  validity  of  the 
results  produced  by  MFSA  relies  heavily  on  user  inputs,  it  is  essential  MFSA  to  provide 
immediate  feedback  on  problems  with  data  inputs.  Where  practical,  it  would  be  helpful  to 
provide  real-time  error  checking,  such  as:  checking  for  typos  (character  in  place  of  a 
number),  logical  inconsistencies  (negative  water  depth),  unit  checking  and  conversion 
(feet  to  meters). 

6.  Track  State 

MFSA  shall  support  tracking  completed  and  remaining  user  actions.  The  user 
time  investment  in  developing  a  scenario  may  be  extensive.  MFSA  must  be  capable  of 
allowing  the  user  to  save  and  return  at  a  later  time  to  continue  development.  Also,  in 
support  of  the  controlled  autonomy  principle  above,  MFSA  should  provide  a  method  for 
tracking  status  to  show  which  tasks  have  been  completed  and  which  remain.  This  feature 
serves  two  purposes;  first,  it  informs  users  how  far  along  they  have  progressed  in  the 
work  flow,  and  it  also  allows  users  to  return  to  where  they  left  off  should  they  decide  to 
logout  for  a  period  of  time. 

2.  Reliability 

The  project  team  evaluated  the  two  components  of  reliability  of  greatest  concern 
to  key  stakeholders  and  user  groups:  the  software  reliability  and  the  database  network 
reliability. 
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1 .  Software  Reliability 

MFSA  shall  reliably  operate  reliably,  conforming  to  user  expectations  for 
reliability.  Software  failures  can  be  minimized  by  proper  detailed  design  and  testing. 
MFSA  development  should  conform  to  MFSA  should  conform  to  the  guidelines  of  IEEE 
PI 63 3,  Recommended  Practice  on  Software  Reliability.  During  MFSA  development, 
appropriate  reliability  studies  should  be  conducted  to  provide  a  suitable  estimate  of  the 
quality  of  the  final  product.  This  involves  modeling  performance,  measuring  key  factors 
for  reliability,  and  implementing  improvements  where  possible. 

2.  Database  Network  Reliability 

MFSA  shall  be  capable  of  operating  in  the  Joint  Information  Environment, 
exchanging  data  with  a  network  of  authoritative  databases  as  well  as  capable  of  operating 
on  shipboard  local  area  networks.  In  Chapter  III,  the  team  identified  the  need  for  MFSA 
to  pull  data  from  authoritative  databases  of  information  via  direct  interface.  Because 
MFSA  may  be  deployed  to  shipboard  networks,  isolated  from  these  authoritative 
databases,  MFSA  must  be  capable  of  operating  without  direct  interface  to  these 
databases. 


3.  Net  Ready  KPP 

MFSA  shall  be  Net  Ready  compliant  in  accordance  with  CJCSI  62 12.0 IF.  The 
Net-Ready  Key  Performance  Parameter  (NR  KPP)  is  a  required  component  of  all  Joint 
Capabilities  Integration  and  Development  System  (JCIDS)  information  system  (IS) 
requirement  documents.  Table  13  provides  a  summary  framework  that  can  be  used  to 
further  develop  MFSA  technical  requirements  and  satisfy  the  three  NR  KPP  attributes. 
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Table  13. 


NR  KPP  Summary  Framework  (adapted  from  JCIDS-M  2015,  D- 

E-5) 


NR  KPP  Attribute 

Attribute  Details 

Measures 

Support  to  military 
operations 

Counter-Mobility/ 

Naval  Mine  Warfare 

Hours  delay  in  enemy  force 
movements  caused  by  mines/ 
obstacles. 

%  of  enemy  forces  unable  to 
reach  their  objective  due  to  mines/ 
obstacles. 

NTA  1 .4. 1 . 1  Plan  Minefields 

NTA  5.4.3. 6  Coordinate 

Offensive  Mining  Operations 

Hours  to  coordinate  minefield 
plan  and  input  to  mine  tasking 
order. 

Planned  minefield  effectiveness 
achieved  at  >  50%  SIT. 

Enter  and  Managed  on 
network 

Joint  Information  Environment 
Shipboard  Tactical  Network 

MOP  for  entering  network 

MOP  for  management  in  network 

Effectively  Exchanges 
information 

Consumes  data  on  environment, 
threats,  and  systems. 

Produces  information  on 
minefield  plan  and  performance 

MOP  for  information  exchange 

4.  Cyber  Security  and  Information  Assurance 

MFSA  shall  conform  to  information  security  requirements  of  DoDI  8500.0 IE 
“Cybersecurity”  and  DoDI  8510.01  “Risk  Management  Framework  for  DOD  Information 
Technology.”  Four  policy  requirements  of  particular  importance  to  MFSA  are 
summarized  below. 

1 .  Risk  Management 

Cybersecurity  threats  shall  be  managed  by  a  multi-tiered  risk  management 
approach.  This  process  ensures  risks  and  vulnerabilities  of  a  system  are  properly 
identified,  tracked,  and  mitigated  in  order  to  protect  DOD  information  and  assets. 

2.  Operational  Resilience 

Information  and  services  are  available  to  authorized  users  when  required.  This 
involves  implementing  a  security  posture  that,  whenever  possible,  provides  the  ability  to 
reconfigure,  optimize,  self-defend,  and  recover  with  little  or  no  human  intervention. 
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3.  Integration  and  Interoperability 

Requires  that  each  IS  achieve  interoperability  by  adherence  to  DOD  standards  and 
instructions,  ensuring  that  vulnerabilities  are  not  introduced  to  a  network  through  a  weak 
node  or  system. 

4.  Identity  Assurance 

Provides  assurance  that  only  authorized  users  can  gain  access  to  systems  and 
eliminates  anonymity  on  networks  by  implementing  Public  Key  Infrastructure  (PKI)  as  a 
means  to  manage  user  identity. 

B.  MAINTAINABILITY  AND  SUPPORTABILITY  REQUIREMENTS 

Software  maintenance  is  the  modification  of  a  software  product  after 

delivery  to  correct  faults,  to  improve  performance  or  other  attributes. 

(ISO/IEC  14764:2006) 

MFSA  shall  receive  updates  and  patches  to  add  functionality,  support  hardware 
and  operating  system  upgrades,  and  correct  user  identified  errors.  While  maintenance  is 
generally  associated  with  fixing  defects,  the  MFSA  conceptual  design  also  involves 
administrative  maintenance,  described  in  Chapter  III,  to  maintain  the  currency  and 
accuracy  of  information  used  to  describe  assets  and  threats  in  the  simulation 
architecture.  Thomas  Pigoski  suggests  that  roughly  80%  of  software  maintenance  efforts 
are  non-corrective  actions.  This  rather  extensive  effort  involves  adding  features  to 
improve  functionality  and  user  experience.  As  described  previously,  the  architecture  of 
the  software  relies  on  local  administrators  to  update  and  maintain  technical  accuracy  for 
specifications  of  simulated  assets.  These  administers  will  also  implement  updates  and 
patches. 

MFSA  shall  include  an  interactive  electronic  technical  manual  (IETM).  This 
manual  represents  the  minimum  level  of  supportability  required  and  will  provide  the  user 
with  tutorials,  explanations  of  features,  and  instructions  for  use.  In  addition  to  the  static 
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help  file,  the  team  anticipates  an  online  community  of  practice  utilizing  a  secure  service, 
such  as  Intellipedia, 1 1  to  share  FUWS  architectural  designs  and  lessons  learned. 


1 1  Intellipedia  provides  a  secure,  online  environment  for  collaborative  data  sharing  by  the  Intelligence 
Community  and  Department  of  Defense. 
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V.  PROPOSED  ARCHITECTURE 


The  two  architectures  [functional  and  physical]  are  developed  in  parallel 
but  with  close  interaction  to  ensure  that  the  allocated  architecture  is 
meaningful  when  the  functional  and  physical  architectures  are  combined. 

(Buede  2009,  27) 

This  chapter  proposes  a  MFSA  architecture,  including  functional  and  physical  (or 
structural)  expressions  and  the  allocation  of  identified  requirements  to  the  architecture. 
While  the  architectures  are  discussed  in  separate  sections  for  clarity  and  organization, 
development  of  the  architectures  in  the  Innoslate72  MBSE  tool  ensured  the  architectures 
were  appropriately  traceable. 

A.  FUNCTIONAL  ARCHITECTURE 

[A  function  is]  an  activity  or  task  that  the  system  performs  to  transform 
some  inputs  into  outputs  (Buede  2009,  211) 

An  Action  . . .  specifies  the  mechanism  by  which  inputs  are  transformed 
into  outputs.  (LML  2013,  11) 

Using  a  top-down  approach,  the  team  began  by  decomposing  the  context  action, 
Action. 0.0  Perform  MFSA  Actions ,  into  the  top-level  actions  shown  in  Figure  19.  The 
team  proceeded  to  use  SysML  sequence  diagrams  to  communicate  system  interactions 
and  LML  action  diagrams  to  communicate  the  required  system  behavior. 


Action.1.0 


Figure  19.  Perform  MFSA  Action  Diagram 


II 2  Innoslate  is  a  collaborative  web  based  tool,  developed  by  SPEC  Innovations,  that  supports 

development  of  model  based  artifacts  and  execution  of  model  verification  simulations.  Innoslate  supports  a 
number  of  architectural  artifacts  in  both  Life  cycle  Modeling  Language  (LML)  and  Systems  Modeling 
Language  (SysML). 
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The  first  sequence  of  actions,  shown  in  the  top  parallel  of  Figure  19,  is 
representative  of  the  actions  taken  by  the  user  to  define  a  scenario,  simulate  the  scenario 
and  review  the  results  of  the  scenario.  In  parallel  with  these  actions,  the  system 
administrator  maintains  the  system.  This  includes  pre -populating  the  system  with  the 
required  information  to  support  simulation  of  new  FUWS  technologies,  alleviating  the 
legacy  burden  on  the  end-user  of  validating  and  formatting  data  inputs. 

1 .  Establish  FUWS  Scenario 

Decomposing  the  first  action,  Action.  1.0  Establish  FUWS  Scenario  Architecture , 
the  team  developed  a  sequence  diagram,  Figure  20,  to  show  the  interactions  required  in 
the  development  of  a  FUWS  Scenario.  This  diagram  shows  the  user  logging  into  MFSA, 
selecting  the  desired  scenario  type,  and  selecting  the  desired  FUWS  architectural 
components.  Included  in  the  selection  of  scenario  type  are  options  to  open  previous 
scenarios,  template  scenarios,  and  new  blank  scenarios.  Once  the  selected  scenario  space 
has  opened,  the  user  selects  the  FUWS  architectural  components. 


Figure  20.  Sequence  Diagram  of  Action  1.0  Establish  FUWS  Scenario 

This  sequence  diagram  can  be  viewed  as  a  LML  Action  Diagram,  as  seen  in 
Figure  21.  In  addition  to  the  sub-actions  shown  sequence  diagram,  the  action  diagram 
shows  the  inputs  (or  triggers)  and  outputs  from  each  action. 
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Figure  21 .  Action  Diagram  of  Action.  1 .0  Establish  FUWS  Scenario 


The  team  continued  with  decomposing  Action.  1.5  Select  FUWS  Scenario  to 
highlight  the  functionality  of  the  MFSA  system.  The  sequence  diagram  of  Figure  22 
shows  specific  interactions  between  the  user  and  MFSA  required  in  defining  the 
minefield  environment,  in  specifying  the  FUWS  assets  (sensors,  communicators  and 
weapons)  that  comprise  the  minefield,  and  in  integrating  those  assets  in  a  selected 
configuration.  The  user  may  also  select  the  anticipated  target  scenario  and  desired  MOPs. 
Throughout  the  selection  process,  MFSA  confirms  that  selections  are  both  valid  and 
congruent.  If  selection  conflicts  with  previous  selection,  MFSA  will  inform  the  user  of 
the  conflict. 
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Figure  22.  Sequence  Diagram  of  Action.  1.5  Select  FUWS  Scenario 
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By  displaying  Action.  1.5  Select  FUWS  Assets  as  a  SysML  Action  Diagram,  the 
team  was  able  to  incorporate  an  OR  construct  to  differentiate  between  the  use  of  MFSA 
as  an  operational  planning  tool  and  a  capability  development  tool.  As  shown  in  Figure  23, 
the  user  can  either  select  Action.  1.5. 4  Select  FUWS  Assets  to  evaluate  or  maximize  the 
performance  of  a  given  set  of  capabilities  or  select  Action  1.5.5  Input  FUWS  Parameters 
to  input  desired  performance  parameters,  using  MFSA  to  generate  a  set  of  required 
components. 


Figure  23.  Action  Diagram  of  Action.  1.5  Select  FUWS  Scenario 

2.  Run  Minefield  Simulation 


After  the  system  collects  the  required  inputs  to  establish  the  scenario,  MFSA 
utilizes  Monte  Carlo  simulations  in  Action. 2.0  Run  Minefield  Simulation  to  translate  these 
inputs  into  the  desired  outputs.  This  action,  shown  in  Figures  24  and  25,  begins  when  the 
user  initiates  the  simulation.  As  seen  in  the  sequence  diagram  the  simulation  uses  the 
information  previously  selected  by  the  user  to  generate  data  sets  and  calculate  the 
required  MOEs. 
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Figure  24.  Sequence  Diagram  of  Action.2.0  Run  Minefield  Simulation 


Figure  25.  Action  Diagram  of  Action.2.0  Run  Minefield  Simulation 


3.  Review  Output 

The  final  step  in  the  MFSA  user  sequence  is  the  Action. 3.0  Review  Output  Action, 
decomposed  in  Figures  26  and  27.  In  this  action,  MFSA  generates  a  formatted  output 
report  that  is  significant  and  meaningful  for  the  user.  The  action  is  initiated  by  the  user 
requesting  the  output  report  or  automatically  upon  completion  of  the  run  simulation 
action.  The  output  report  module  requests  data  from  the  simulation  module  and  formats 
the  data  into  a  clear  and  concise  report  for  the  user.  Not  shown  in  these  figures  is  the 
potential  for  the  user  to  decide  to  re -perform  the  analysis  with  a  modified  set  of  inputs. 
This  would  represent  a  system-wide  loop,  as  the  user  would  return  to  Action.  1.0  to  make 
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the  desired  revisions.  This  looped  process  would  continue  until  the  user  gathers  all 
required  data  and  results. 


Us«r  Simulation  Module  ^Modute^ 


^RequestOijtputReport^ 


Request  Output  Date 


|  Provide  Output  Data 
Pormatj  Report 


Figure  26.  Sequence  Diagram  of  Action.3.0  Review  Output 


Figure  27.  Action  Diagram  of  Action.3.0  Review  Output 


4.  Maintain  MFSA 

As  seen  previously  in  Figure  19,  in  parallel  with  these  tasks,  MFSA  must  be 
maintained.  This  could  include  the  system  administrator  updating  the  different  MFSA 
modules  to  remove  software  bugs,  providing  future  system  usability  enhancements,  and 
updating  databases  to  reflect  changes  in  FUWS  technologies,  targets  or  environments. 

As  shown  in  Figures  28  and  29,  in  Action. 4.0  Maintain  MFSA  the  system 

administrator  logs  into  MFSA  with  a  different  login  protocol  from  the  user.  This  provides 

the  system  administrator  with  greater  permissions  to  access  and  alter  system  components. 
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As  the  system  administrator  makes  updates  to  the  different  modules,  MFSA  provides 
prompts  to  confirm  the  updates  prior  to  allowing  the  administrator  to  promulgate  updates 
to  other  users. 
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Figure  28.  Sequence  Diagram  of  Action.4.0  Maintain  MFSA 


Figure  29.  Action  Diagram  of  Action.4.0  Maintain  MFSA 
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B.  STRUCTURAL  ARCHITECTURE 


The  physical  architecture  provides  resources  for  every  function  identified 

in  the  functional  architecture.  (Buede  2009,  253) 

Because  the  MFSA  system  is  an  information  system,  many  of  the  assets13  in  the 
“physical”  architecture  are  software  components  that  perform  allocated  functions.  As 
such,  the  team  utilized  the  term  “structural”  to  include  traditional  “physical”  system 
architecture  components  as  well  as  non-tangible,  software  module  assets. 

1.  Structural  Hierarchy 

As  seen  in  Figure  30,  the  MFSA  asset  can  be  decomposed  into  component 
software  modules,  the  supporting  MFSA  software  infrastructure,  and  the  system 
administrator.  The  team  chose  to  include  the  system  administrator  inside  the  system 
boundary  because  this  role  would  be  “created”  as  part  of  the  system  development.  The 
program  analysts  and  operational  planners  that  compose  the  “user”  asset  are  shown 
external  to  the  system  and  there  interactions  with  the  system  are  shown  in  subsequent 
views  of  the  structural  architecture.  Asset. 2.0  FUWS  Scenario  Architecture  Module  was 
further  decomposed  to  highlight  the  components  of  the  FUWS  and  support  traceability  of 
the  previously  identified  (Table  6  in  Chapter  III)  input  requirements. 


Figure  30.  Structural  Hierarchy  Diagram  of  MFSA 


13  An  Asset  is  an  object  (system,  subsystem,  component,  or  element),  person,  or  organization  that 
performs  Actions  (LML  2013,  11) 
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2.  Class  Diagram 

While  useful  for  tracing  the  assignment  of  assets  to  functions  in  the  architectural 
model,  the  hierarchy  diagram  provides  limited  information  about  the  assets  and  their 
relationships.  A  Unified  Modeling  Language  (UML)  Class  Diagram  provides  an 
appropriate  mechanism  for  showing  the  required  relationships  between  the  assets  and 
supports  translating  the  conceptual  modules  into  executable  software  modules.  To 
develop  a  class  diagram  highlighting  the  interactions  of  the  user  with  the  system,  the 
team  began  by  identifying  the  attributes  and  operations  associated  with  the  user  asset 
class.  From  this,  the  team  was  able  to  identify  the  required  interactions  with  component 
MFSA  system  asset  classes.  The  team  proceeded  to  identify  the  required  attributes  and 
operations  associated  with  each  MFSA  asset  as  shown  in  Figure  3 1 . 


Figure  3 1 .  MFSA  User  Interface  Class  Diagram 
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Additional  class  diagrams  developed  to  describe  the  interactions  of  various  assets 
in  more  detail  are  provided  in  Appendix  D. 

C.  FUNCTIONAL  REQUIREMENTS  ALLOCATION 

The  allocated  architecture  integrates  the  requirements  decomposition  with 
the  functional  and  physical  architectures  (Buede  2009,  284) 

This  section  describes  the  team’s  efforts  to  decompose  top-level  requirements  and 
establish  traceability  with  the  actions  and  interfaces  in  the  proposed  architectures. 

1.  Requirements  Hierarchy 

A  Requirement  . . .  identifies  a  capability,  characteristic,  or  quality  factor 
of  a  system  that  must  exist  for  the  system  to  have  value  and  utility  to  the 
user.  (LML  2013,  12) 

As  part  of  the  MFSA  architecture  model  development,  the  identified  requirements 
were  arranged  in  a  hierarchy,  shown  in  Figure  32. 


Req.0.0 

Conduct 

MFSA 


Figure  32.  MFSA  Requirements  Hierarchy 

60 


The  input  and  output  requirement  identified  in  Chapter  III  are  augmented  by 
additional  requirement  discovered  during  the  architecture  development  process. 

2.  Requirement  Allocation 

The  team  used  SysML  Requirement  Diagrams  to  trace  requirements  to 
architecture  elements  that  implement  the  requirements.  The  allocation  of  top-level 
requirements  can  be  seen  in  Figure  33.  The  allocation  of  the  decomposed  requirements  of 
Figure  32  is  provided  in  Appendix  E. 


Req.0.0  Conduct  MFSA  Operations 

i  H 

The  system  shall  conduct  MFSA  operations. 

Req.1.0  Establish  Minefield  Architecture 

The  system  shall  allow  the  user  to  establish  a  minefield 

arc  h  itec  tu  re  sc  enario. 

Req.2.0  Output  Simulation  Data 

The  system  shall  output  simulation  data  into  a  report  for 

the  user. 

Req.3.0  Run  Simulation 

The  system  shall  allow  the  user  to  run  the  simulation  to 
simulate  the  FUWS  architecture  scenario. 

Req.4.0  Updates  Performed  by  System  Administrator 

The  system  shall  be  maintained  by  a  system 

administrator. 

Action. 0.0  Perform  MFSA  Actions 


Figure  33.  High  Level  Requirement  Diagram 
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D.  SPECIFICATION  MATCHING 


If  specification  matching  points  to  an  existing  component  that  fits  the 

needs  of  the  current  application,  you  can  extract  the  component  from  a 

reuse  library  (repository)  and  use  it  in  the  design  of  a  new  system. 

(Pressman  2015,  312) 

As  discussed  in  Chapter  II. C,  the  team  reviewed  GAMET  capabilities  as  part  of 
the  capability  gap  analysis.  During  this  review,  the  team  identified  a  number  of 
capabilities  provided  by  GAMET  that  would  be  appropriate  for  reuse  in  the  MFSA 
architecture.  The  reuse  of  appropriate  capabilities  streamlines  development  efforts  and  by 
using  proven  solutions,  potentially  reduces  validation  and  verification  efforts. 

1.  Dual  User  Modes 

GAMET  employs  of  two  user  modes:  Analysis  Mode  and  Planning  Mode.  In 
Analysis  Mode,  the  user  defines  the  number  of  nodes  in  the  field  in  order  to  evaluate  the 
minefield’s  effectiveness.  In  Planning  mode  the  user  defines  the  desired  effectiveness 
and  GAMET  automatically  determines  the  number  of  nodes  necessary  to  achieve  the 
effectiveness  (Belton  2015,  2).  The  Mental  Focus  team  re-applied  this  basic  architecture 
of  two  user  modes  to  ensure  the  system  provided  capability  to  both  the  program  analyst 
and  operational  planner. 

2.  AUWS  Upgrades 

As  discussed  in  Chapter  II.C,  GAMET  was  upgraded  to  provide  limited  AUWS 
simulation  capability.  To  support  AUWS  simulation,  GAMET  was  modified  to  include 
communication  logic  algorithms  between  sensor  and  weapon  nodes.  This  modification 
was  extended  to  include  probabilistic  determinations  of  successful  communication  and 
user  selectable  decision  logic  options  (Belton  2011,  10).  To  support  evaluation  of  the 
energy  requirements  in  various  AUWS  configurations,  GAMET  was  also  modified  to 
include  energy  usage  parameters.  GAMET  accounts  for  total  energy  consumption,  energy 
consumed  per  detection,  and  energy  consumed  per  message  transmission  (and  receipt)  at 
various  power  levels  (Belton  2011,  19).  The  evaluation  of  energy  requirements  directly 
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supports  evaluation  of  FUWS  design  alternatives.  These  and  other  AUWS  directed 
upgrades  were  incorporated  for  reuse  in  the  MFSA  concept. 

3.  Graphical  User  Interface 

GAMET  includes  a  graphical  display  that  provides  the  user  a  visual 
representation  of  the  minefield  being  simulated.  This  allows  the  user  to  visualize  the 
simulation  and  provides  increased  user  understanding  of  the  capability  under 
consideration.  This  also  allows  the  user  to  capture  graphics  and  images  that  can  be  used 
in  operational  planning  and  capability  development  briefings  as  appropriate  (Belton 
2015,20). 
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VI.  PROTOTYPE  DEVELOPMENT 


Models  attempt  to  represent  the  entities  of  the  engineering  problem 
(opportunities)  and  their  relationships  to  each  other  and  connect  them  to 
the  proposed  solution  or  existing  mechanism  that  addresses  the  problem. 

The  model  used  in  this  way  is  the  centerpiece  of  MBSE.  (Long  and  Scott 
2011,32) 

One  of  the  team’s  goals  (Section  I.D.3,  Goal  4)  was  the  development  of  a 
prototype  simulation  system  (included  at  Appendix  G)  that  demonstrated  the  team’s 
solution  approach.  This  prototype  proved  beneficial  in  developing  a  more  thorough 
understanding  of  the  emergent  behaviors  of  a  distributed  sensor  system  evaluating  the 
performance  differences  from  a  legacy  mine  system.  Given  the  limited  resources 
available,  the  Mental  Focus  team  chose  to  execute  the  prototype  development  as  the  first 
demo  in  a  scrum14  development  process.  To  simulate  this  agile  software  development 
technique,  the  team  conducted  short  semi-weekly  meetings  to  brainstorm  techniques, 
assign  responsibilities,  and  track  progress.  During  the  second  in-progress  review  (IPR) 
the  team  presented  the  prototype  for  “customer  feedback”  from  attending  faculty  and 
students.  In  response  to  this  feedback,  the  prototype  was  updated  to  incorporate 
additional  outputs  desired  by  potential  users. 

A.  METHODOLOGY 

A  primary  reason  for  the  popularity  of  agent  based  modeling  (ABM)  and 
its  departure  from  other  simulation  paradigms  is  that  ABM  can  simulate 
and  help  examine  organized  complex  systems  (OCS).  This  means  the 
ABM  paradigm  can  represent  large  systems  consisting  of  many  subsystem 
interactions.  (Heath  et  al.  2009) 

The  team  began  the  prototype  development  process  by  selecting  a  simulation 
environment  for  use.  The  team  considered  a  number  of  programs,  conducting  a  brief 
analysis  of  alternatives  detailed  in  Appendix  F,  before  selecting  Netlogo15  for  use.  Unlike 


14  Scrum  is  an  agile  software  development  method  conceived  by  Jeff  Sutherland  in  the  1990s. 
Development  work  is  conducted  in  sprints  that  deliver  demonstrations  of  functionality  to  the  customer  for 
evaluation  (Pressman  2015,  78-79). 

15  Netlogo  is  a  free,  open-source  modeling  environment  developed  and  maintained  by  the  Center  for 
Connected  Learning  and  Computer-Based  Modeling  at  Northwestern  University. 
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the  other  programs  considered,  Netlogo  is  an  agent  based  modeling  (ABM)  platform. 
While  not  considered  in  the  initial  selection  of  Netlogo,  the  team  discovered  that  the 
ABM  approach  is  well  suited  to  the  simulation  of  a  FUWS.  Model-Based  Systems 
Engineering  (MBSE)  traditionally  uses  architecture  models  to  decompose  and  allocate 
the  required  system  functional  behaviors  using  various  process  models16  to  manage  the 
complexity  of  the  design  (Buede  2009,  60).  In  contrast,  ABM,  much  like  object  orient 
programming,  begins  with  the  definition  of  agents  or  assets  and  their  attributes.  When 
providing  the  agents  with  decision-making  rule  sets,  ABM  becomes  a  very  capable 
technique  for  simulating  the  actions  and  interactions  of  large  numbers  of  “like”  agents, 
such  as  the  sensors  and  weapons  in  a  FUWS. 

1.  Notation 

Every  modeling  technique  is  a  language  used  to  represent  reality  so  that 

some  question  can  be  answered  with  greater  validity  than  could  be 

obtained  without  the  model.  (Buede  2009,  59) 

Netlogo  primitive  agents  are  grouped  into  four  distinct  agent-sets: 

1.  The  observer  is  a  single  agent  that  observes  and  directs  the  actions  of 
other  agents  in  the  model. 

2.  Patches  are  fixed  background  agents  that  form  the  environment  on  which 
other  agents  act. 

3.  Turtles  are  agents  that  can  move,  interacting  with  both  patches  and  other 
turtles. 

4.  Links  are  agents  that  connect  turtles,  establishing  an  enduring  relationship 
between  two  turtles 

Subsets  of  these  primitive  agent-sets  can  be  established  by  creating  “breeds”  of 
turtles  or  links  with  custom  attributes  and  by  “asking”  groups  of  agents  about  their 
parameters,  including  relationships  with  other  agents.  This  allowed  the  programmer  to 


16  The  Enhanced  Function  Flow  Block  Diagram  (EEFBD),  ICAM  Definition  for  Function  Modeling 
(IDEF0),  N2  Diagram,  SysML  Sequence  Diagram,  SysML  Activity  Diagram,  and  LML  Action  Diagram  all 
decompose  functional  behavior  (Long  and  Scott  2014,  39M4)  by  tracing  the  processing  of  energy,  matter, 
material  wealth  and  information  (EMMI)  through  the  system. 
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develop  simple,  condition  based  behavior  heuristics  and  apply  them  to  large  numbers  of 
agents,  simplifying  the  model  development  process. 

2.  Scrum  Backlog 

The  scrum  development  process  uses  a  backlog  to  track  the  user  functions 
targeted  for  development  in  the  sprint.  To  scale  and  prioritize  the  development  of 
requirements  identified  in  Chapters  III  and  IV,  the  team  developed  the  following 
simulation  goals  for  the  prototype  structured  using  the  decide,  detect,  deliver,  assess 
(D3A)  targeting  methodology  used  by  Maritime  Component  Commanders  (JP  3-60,  C-l) 
and  shown  in  Figure  34. 

1.  Decide.  The  prototype  would  allow  the  user  to  decide  to  employ  either  a 
legacy  mine  capability  or  FUWS.  The  simulation  would  support  this 
decision  by  simulating  the  deployment  of  the  selected  capabilities  in  a 
two-dimensional  counter-mobility  area  using  selected  algorithms. 

2.  Detect.  The  prototype  would  simulate  sensors  capable  of  detecting  the 
proximity  of  a  hostile  contact. 

3.  Deliver.  The  prototype  would  simulate  weapons  capable  of  delivering 
mission  kill  effect.  This  includes  simulating  explode-in-place  weapons  in  a 
legacy  architecture  and  intercept-to-engage  weapons  in  a  FUWS 
architecture. 

4.  Assess.  The  prototype  would  calculate  system  MOPs  for  assessment  by 
the  user.  This  would  include,  at  a  minimum,  the  SIT  and  threat  profile. 


Figure  34.  D3A  Targeting  Methodology. 
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B.  REFERENCE  SCENARIO 


The  team  developed  a  simple  reference  scenario  that  could  be  used  to  evaluate  the 
effectiveness  of  counter-mobility  architectures.  As  shown  in  Figure  35,  hostile  surface 
ships  approach  the  western  entrance  of  a  maritime  straight  with  the  goal  of  transiting  to  a 
point  east  of  the  straight.  To  limit  the  hostile  forces’  mobility,  the  friendly  commander 
deploys  a  counter-mobility  capability  in  the  10  nm  by  10  nm  area  shown.  Multiple 
surface  ships  will  sequentially  attempt  to  transit  the  area,  requiring  the  friendly 
commander  to  possess  a  sustained  counter-mobility  capability. 


Figure  35.  Scenario  Laydown 


1.  Assumptions 

...  it  is  a  mistake  to  ascribe  objectivity  to  models.  Complex  mathematical 
models  have  subjective  assumptions  throughout  them.  (Buede  2009,  60) 

The  following  assumptions  were  explicitly  made  in  the  development  of  the 
prototype  model  to  maintain  simplicity  and  demonstrate  the  selected  modeling  approach. 

1 .  Hostile  contacts  do  not  maneuver  within  the  minefield  area 

2.  Sensor  detections  can  be  assumed  to  occur  at  a  fixed  range  as  opposed  to  a 
probabilistic  function  of  target  signal  strength  and  sensor  sensitivity 

3.  Sensor  false  detect  rate  is  low  and  can  be  neglected 
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4.  Data  latency  in  the  system  is  low,  and  can  be  neglected 

5.  Warhead  detonations  within  a  fixed  range  always  result  in  a  mission  kill 
with  no  partial  damage 

With  these  assumptions,  the  model  results  should  not  be  used  to  predict  absolute 
system  behavior  but  can  be  used  to  establish  the  relative  behavior  of  the  solutions  under 
consideration  and  provide  a  framework  for  further  development  and  refinement.  The 
chosen  modeling  environment  is  robust  enough  to  support  reducing  these  assumptions 
and  increasing  the  accuracy  of  the  model  in  subsequent  sprints. 

2.  Conceptual  Model 

ABM  begins  with  assumptions  about  agents  and  their  interactions  and  then 
uses  computer  simulation  to  generate  “histories”  that  can  reveal  the 
dynamic  consequences  of  these  assumptions.  Thus,  ABM  researchers  can 
investigate  how  large-scale  effects  arise  from  the  micro-processes  of 
interactions  among  many  agents.  (Axelrod  and  Tesfatsion  2015) 

Using  a  “middle  out”  engineering  approach  (Long  and  Scott  2011,  14),  the  first 
solution  concept  developed  was  the  “as  is”  naval  mine  solution.  Sensors  within  a  given 
range  of  the  hostile  ship  detect  the  ship  and  send  a  signal  to  the  connected,  collocated 
weapon  to  detonate.  If  the  detonation  occurs  within  the  blast  radius  of  the  weapon,  the 
system  achieves  a  mission  kill  and  the  hostile  ship  dies. 

While  the  “as  is”  mine  is  conceptually  simple,  the  FUWS  concept  is  much  more 
complicated  and  requires  more  attributes  for  the  sensors  and  weapons.  In  this  conceptual 
model,  a  sensor  network  is  deployed  separate  from  a  number  of  torpedo  batteries.  When  a 
sensor  detects  a  hostile  ship  it  informs  all  sensors  within  a  given  communication  radius 
that  it  has  detected  a  threat.  These  sensors  act  as  relays  passing  on  the  detection  of  the 
threat  to  additional  sensors  and  eventually  to  the  UUV  batteries.  The  “next  to  fire” 
torpedo  in  the  network  is  then  aimed  based  on  the  location  of  the  detecting  sensor  and  a 
simplistic  targeting  logic,  assumed  hostile  ship’s  course  and  speed.  Once  fired,  the 
torpedo  loses  communication  with  the  network  and  attempts  to  gain  organic  contact  on 
the  hostile  ship  using  a  forward-looking  cone  of  acquisition.  If  the  torpedo  “sees”  the 


69 


ship,  it  will  home  on  the  ship  until  it  reaches  a  range  where  it  detonates,  killing  the  ship. 
If  the  torpedo  fails  to  “see”  the  ship,  it  will  eventually  run  out  of  fuel  and  shutdown. 

C.  COMPUTER  MODEL 

There  are  major  advantages  arising  from  using  models  as  the  basis  of 
systems  engineering.  (Long  and  Scott  2011,  65) 

To  translate  these  conceptual  models  into  a  functional  computer  simulation,  the 
team  decomposed  Asset  2.2  FUWS  Assets  of  Chapter  V.B  and  allocated  some  of  the  basic 
input  requirements  of  Chapter  III  to  the  asset  subclasses.  To  support  the  translation  of  the 
conceptual  design  into  the  Netlogo  modeling  environment,  a  UML  class  diagram,  shown 
in  Figure  36,  was  used  to  map  the  FUWS  asset  components  onto  the  Netlogo  primitive 
agents. 


Figure  36.  UML  Class  diagram  of  Agent  Breeds  and  Attributes 
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1.  User  Interface 


The  prototype  computer  model  user  interface  is  shown  in  Figure  37  with 
additional  views  shown  in  Appendix  G.  On  the  left  of  the  screen  are  user-selected  inputs 
to  the  model.  The  user  begins  by  selecting  the  desired  counter-mobility  system 
architecture  and  tactics  from  the  sim-type  dropdown.  The  sim-runs  input  box  sets  the 
number  of  Monte-Carlo  simulation  run  and  the  FixedField  toggle  determines  if  a  new 
randomized  undersea  weapon  system  deployment  laydown  is  generated  between 
simulation  runs. 

To  model  a  legacy  minefield,  the  user  selects  either  a  “radial  minefield”  (mines 
are  laid  in  lines  passing  near  the  center  of  the  counter-mobility  area)  or  a  “vertical 
minefield”  (mines  are  laid  in  rows  across  the  transit  axis)  from  the  sim-type  dropdown. 
The  user  then  selects  the  total  quantity  of  mines  and  the  number  of  lines  in  which  they  are 
deployed  using  the  Undersea  Weapon  System  Parameters  slider  bars,  Lines  and  MineQty. 

To  model  a  FUWS,  the  user  selects  fuws  from  the  sim-type  dropdown.  The  user 
then  selects  the  total  quantity  of  sensors  ( SensorQty ),  the  number  of  lines  in  which  the 
sensors  are  deployed  {Lines),  then  number  of  torpedoes  {MobileWeaponQty)  and  the 
number  of  batteries  ( UUVQty )  in  which  the  weapons  are  deployed  using  the  appropriate 
Undersea  Weapon  System  Parameters  slider  bars. 
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Figure  37.  Prototype  Demonstration 

The  user  controls  the  setup  and  tactics  of  the  threat  using  the  Enemy  Vessel 
Parameters  slider  bars.  The  t-speed  slider  sets  the  transit  speed  of  the  target  vessels  and  t- 
number  sets  the  number  of  sequential  vessels  transiting  in  each  simulation  run.  The  t- 
tactic  drop  down  is  used  to  select  the  tactic  used  by  the  threat  vessels:  direct-path 
(vessels  transit  directly  from  their  random  points  of  origin  to  the  goal),  center-line 
(vessels  transit  a  Iky  wide  path  thru  the  center  of  the  counter-mobility  area),  or  edge-line 
(vessels  transit  a  Iky  wide  path  randomly  selected  away  from  the  center  of  the  counter¬ 
mobility  area). 

After  setting  up  the  weapon  system  and  threat,  the  user  must  click  on  the  Initialize 
button  to  update  the  settings  in  the  model  and  the  Start-Sim  button  to  begin  the  series  of 
simulations. 

In  the  center  of  the  screen  is  a  graphic  overview  of  the  simulation.  Sensors  are 
shown  as  circles,  weapons  as  exes,  and  threat  vessels  as  diamonds.  In  the  FUWS  mode, 
the  communications  network  links  are  shown  in  grey  to  support  user  visualization  of  the 
communications  network.  As  the  simulation  runs,  the  user  can  watch  the  interactions  of 
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the  threat  with  the  sensors  and  weapons,  observing  the  effectiveness  of  the  weapon 
system  and  the  potential  weaknesses  of  the  system. 

On  the  right  side  of  the  screen  are  a  number  of  output  MOPs.  The  bar  graph 
shows  the  calculated  threat  presented  to  each  sequential  transiting  vessel.  Point  estimates 
of  the  simple  initial  threat  (SIT),  standard  error  of  the  SIT,  and  expected  casualties  (EC) 
are  output  in  the  monitor  windows  below  the  graph.  Also  shown  in  FUWS  scenarios  are 
the  number  of  misses  (torpedoes  expended  but  that  failed  to  hit)  per  simulation  run. 

2.  Verification  and  Validation 

Because  the  prototype  simulation  system  was  developed  as  a  demonstration  for 
communication  with  stakeholders,  it  was  subjected  to  a  limited  verification  and  validation 
process.  System  verification  was  conducted  using  limited  software  smoke  testing 
(Pressman  2015,  479)  during  each  programming  day.  As  new  features  were  added,  the 
simulation  was  debugged  and  executed  to  ensure  it  behaved  as  expected.  System 
validation  was  conducted  using  a  beta  testing  (Pressman  2015,  485)  strategy  with  other 
members  of  the  Mental  Focus  team  acting  as  end-users. 

3.  Results 

Was  planned  minefield  effectiveness  achieved  at  >  50%  SIT?  (Dept,  of  the 

Navy  2007,  Performance  Metric  #2  of  task  NTA  5. 4. 3. 6  Coordinate 

Offensive  Mining  Operations) 

The  prototype  simulation  system  was  developed  to  demonstrate  the  team’s 
conceptual  solution  approach  and  support  additional  requirement  discovery.  The  data  in 
the  system  is  generic  and  not  representative  of  existing  or  planned  systems.  As  such,  the 
comparison  of  simulation  predictions  to  real  world  performance  should  not  be  conducted 
and  is  outside  the  scope  of  this  project.  Despite  these  limitations,  the  prototype  simulation 
system  was  useful  in  answering  some  of  the  team’s  initial  study  questions. 

The  standard  minefield  effectiveness  metric  in  current  use  is  the  simple  initial 
threat  (SIT),  or  the  probability  that  the  first  hostile  ship  to  transit  the  minefield  (hostile 
shipi)  is  killed  (equation  1). 
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SIT  =  /?(hostile  shipj  killed)-  kt  In 


(1) 


Where  k\  is  the  number  of  times  the  first  hostile  ship  is  killed  and 

n  is  the  number  of  scenarios  run 

While  operational  planners  currently  focus  on  the  SIT  MOP,  looking  at  how  the 
minefield’s  performance  changes  with  time  provides  a  more  holistic  understanding  of 
system  performance.  By  extending  the  concept  of  the  threat  presented  by  the  minefield  to 
the  /th  hostile  ship  (equation  2),  one  can  develop  a  threat  profile  (T)  vs.  transit  sequence 
number  (i). 

Ti  =  ^(hostile  ship;  killed)  ~  kj  n  (2) 

Another  useful  metric  is  the  expected  casualties  (EC)  shown  in  equation  3.  EC 
provides  the  warfighter  with  an  estimate  of  the  reduction  in  the  enemy  force,  should  the 
enemy  attempt  to  transit  the  minefield. 

EC  =  ii  (hostile  ship’s  killed)  ~  ^  w  (3 ) 

To  highlight  the  value  of  the  MFSA  tool,  the  team  used  BehaviorSpace17  to 
explore  the  capability  provided  by  the  FUWS  parameters  described  in  Table  14  and  the 
legacy  mine  parameters  described  in  Table  15.  By  varying  the  parameters  identified  (and 
underlined)  in  Tables  14  and  15,  the  team  was  able  to  use  Monte  Carlo  simulations  of  the 
systems  to  show  the  impact  on  capability  performance.  Using  BehaviorSpace,  the  team 
conducted  a  “sweep”  of  the  parameter  space  by  conducting  Monte  Carlo  simulations  for 
twelve  different  implementations  of  both  the  legacy  minefield  and  the  FUWS 
architecture.  The  results  of  these  scenarios  were  post  processed  in  Excel  and  summary 
statistics  are  provided  in  Appendix  H. 


17  BehaviorSpace  is  a  tool  integrated  with  NetLogo  that  allows  users  to  systematically  vary  a  model’s 
parameters  and  explore  combinations  of  settings. 
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Table  14. 

FUWS  Model  Parameters 

Weapons 

Single  speed,  45kts,  torpedoes  with  passive 
seekers  having  a  45°  cone  of  acquisition  and 
detection  range  of  2kyds,  and  with  blast  radius  of 
N(|u=200  yd,  g=12  yd) 

Weapon 

arrangement 

6  weapons  distributed  on  1,  2,  or  3  stationary 

UUV  launchers 

Sensor 

Networked  sensors  with  detection  range 

N(p=200  yd,  a=25  yds)  against  all  hostile  ships 

Total  Sensors 

50  or  100  distributed  in  either  2  or  5  vertical  lines 

Communicators 

Sensor-sensor  communications  ranges  of  4kyds 
and  sensor-UUV  communication  ranges  of 
lOkyds  with  negligible  data  latency.  The 
communicators  pass  the  geographic  location  of  a 
detecting  sensor. 

Table  15. 

Legacy  Mine  Model  Parameters 

Weapons 

Explode  in  place  warheads  with  blast  radius: 
N(ju=200  yd,  o=12  yd) 

Weapon 

arrangement 

50,  60,  70,  80,  90,  or  100  mines  distributed  in 
either  5  or  10  “Vertical”  mine  lines 

Sensor 

Integrated  sensor  with  detection  range  N(|u=200 
yd,  g=25  yd)  against  all  hostile  ships 

Figure  38  shows  the  resulting  threat  profile  estimate  for  each  configuration  with 
FUWS  data  points  plotted  in  green  and  legacy  mine  data  points  plotted  in  blue.  While  the 
independent  variable  is  not  time,  the  sequential  nature  of  the  hostile  ships  transiting  the 
field  provides  a  proxy  that  allows  us  to  show  system  performance  trends  without  focusing 
on  the  single  system  metric  of  SIT.  The  arrows  show  the  general  shape  of  the  data  series 
associated  with  each  architecture  configuration.  While  the  legacy  mines  present  a 
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capability  that  decays  exponentially,18  the  FUWS  provides  a  nearly  static  capability  that 
only  begins  to  decay  as  the  number  of  threat  ships  approaches  the  number  of  weapons  in 
the  system.19  As  a  result,  while  all  the  system  configurations  modeled  begin  with  a  SIT 
between  0.4  and  0.8,  by  the  arrival  of  the  third  transiting  vessel,  the  FUWS  systems  are 
significantly  out  performing  legacy  systems.  The  change  in  the  shape  of  the  performance 
data  is  significant  and  addresses  the  second  study  question  (Chapter  I).  The  change  in  the 
threat  profile  indicates  that  the  FUWS  will  sustain  its  performance  while  weapons  remain 
in  the  system  and  is  an  emergent  property  of  the  FUWS  architecture. 

Systems  thinkers  use  graphs  of  system  behavior  to  understand  trends  over 
time  rather  than  focusing  attention  on  individual  events.  (Meadows  and 
Wright  2008,  20) 
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Figure  38.  Threat  Profile 


18  Fits  of  exponential  decay  curves  (y=ae‘bx)  to  of  each  of  the  legacy  twelve  systems  resulted  in  an 
average  R2  value  of  0.987,  with  a  minimum  of  0.971,  indicating  that  the  simulation  results  show  an 
exponential  decay  of  capability. 

19  The  best  fit  curve  to  the  FUWS  data  was  a  second  order  polynomial  (y=ax2+bx+c)  with  a 
“maximum”  near  the  first  or  second  transistor  and  an  average  R2  value  of  .881,  with  a  minimum  of  0.687. 
The  fit  coefficients  indicate  that  the  curves  to  a  good  job  of  describing  the  shape  of  the  performance  data. 
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Also  of  note,  the  team  observed  a  strong  linear  relationship  between  the  SIT  and 
the  components  of  the  threat  profile.  As  seen  in  Figure  39,  the  single  parameter  of  SIT  is 
a  strong  indicator  for  the  T2.  This  linear  relationship  holds  for  T3  thru  T6.  Also,  since  EC 
is  the  sum  of  threat  profile  componets,  EC  could  also  be  expressed  as  a  function  of  the 
SIT  (Figure  38).  As  such,  the  team  began  to  understand  the  predominance  of  the  SIT  in 
current  minefield  planning  doctrine  and  measure.  Within  the  legacy  architecture,  the 
threat  profile  and  EC  are  redundent  measures  to  the  SIT.  However,  when  comparing  the 
FUWS  architecture  to  the  legacy  architecture,  the  SIT  is  not  adequate  to  describe  the 
change  in  capability. 
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Figure  39.  T2  as  a  Function  of  SIT 


One  can  readily  see  from  Figure  40  that  using  the  predicted  SIT  to  compare  a 
legacy  mine  system  to  a  FUWS  does  not  adequately  describe  the  differences  in 
performance.  For  example,  the  FUWS  system  with  a  SIT  of  0.42  has  a  predicted  EC  of 
2.5  ships  and  outperforms  the  legacy  system  with  a  SIT  of  0.78  and  an  EC  of  2.2  ships. 
Note  that  the  FUWS  curve  is  above  the  legacy  curve,  indicating  a  higher  EC  for  a  given 
SIT,  and  has  a  steeper  slope  than  the  legacy  curve,  indicating  that  this  difference  is  more 
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pronounced  at  higher  SIT  values.  Since  the  EC  is  operationally  relevant  to  the  Naval 
Warfighter,  translating  into  an  expected  reduction  in  enemy  capability,  the  team  contends 
that  EC  should  take  precedence  over  SIT,  especially  when  comparing  different  FUWS 
architectures. 
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Figure  40.  EC  as  a  Function  of  SIT 


4.  Cost  Benefit  Analysis 

Finally,  to  demonstrate  the  value  of  MFSA  to  program  analysts,  the  team 
developed  a  rough  order  of  magnitude  life  cycle  cost  (LCC)  model  (Equations  4  and  5) 
and  compared  the  cost  effectiveness  of  the  various  solutions  in  current  year  dollars 
(CY$). 


iCCmta  =Mx(C 


+c 

procurement  sustainment 


+  ^recovery  +  Qispoial )+ ML  X  C( 


deployment 


(4) 


Where  M  is  the  number  of  mines  deployed  in  the  minefield 
Cprocurement  is  the  mine  procurement  cost  in  CY$  (assumed  $  1,000/mine) 

Csustainment  is  the  average  mine  sustainment  cost  in  CY$  (assumed  $  1,000/mine) 
Crecoveiy  is  the  average  mine  recovery  cost  in  CY$  (assumed  $  10,000/mine) 
Cdisposai  is  the  average  mine  disposal  cost  in  CY$  (assumed  $  1,000/mine) 

ML  is  the  number  minelines  and 

Cdepioyment  is  the  average  cost  to  deploy  a  mineline  in  CY$  (assumed  $  10,000/line) 


78 


LCQ 


FUWS 


=  Wx(C 
+UUV ) 
+Sx(C 


(5) 


Where  W  is  the  number  of  weapons  deployed  in  the  minefield 

Cw  procurement  is  the  average  weapon  procurement  cost  in  CY$  (assumed  $  100,000/weapon) 

^w. sustainment  is  the  average  weapon  sustainment  cost  in  CY$  (assumed  $  1,000/weapon) 

Cw.disposai  is  the  average  weapon  disposal  cost  in  CY$  (assumed  $  1,000/weapon) 

UUV  is  the  number  of  UUV  weapon  batteries  deployed 

Cuuv.depioyment  is  the  LCC/deployment  of  a  UUV  in  CY$  (assumed  $100,000/UUV) 

Cuuv.recovery  is  the  cost  to  recover  a  UUV  in  CY$  (assumed  $10,000/UUV) 

S  is  the  number  of  sensors  deployed 

^procurement  is  the  average  sensor  procurement  cost  in  CY$  (assumed  $  1,000/sensors) 

Cs sustainment  is  the  average  sensor  sustainment  cost  in  CY$  (assumed  $  1,000/weapon) 

SL  is  then  number  of  sensor  lines  and 

^.deployment  is  the  average  cost  to  deploy  a  sensor  line  in  CY$  (assumed  $10, 000/line) 

To  support  subsequent  analysis,  the  costs  were  then  normalized  to  a  scale  of  “0” 
(20%  higher  than  the  highest  calculate  cost)  to  “1”  (20%  lower  than  the  lowest  cost 
calculation).  While  very  rough  estimates,  these  cost  models  enabled  the  team  to 
demonstrate  the  value  of  MFSA  in  an  acquisition  analysis  of  alternatives.  Figure  41 
shows  a  plot  of  SIT  as  a  function  of  the  normalized  LCC  for  each  alternative  considered. 
From  the  graph,  one  can  see  that  the  FUWS  and  legacy  architectures  provide  competitive 
levels  of  performance  at  the  same  general  cost  levels;  that  is  the  alternatives  from  both 
architectures  are  clustered  together.  However,  for  a  given  cost,  the  maximum  SIT 
performance,  shown  by  the  Pareto  Frontier,  is  dominated  by  legacy  solutions  sets. 

The  team  also  performed  this  analysis  using  EC  as  the  discriminating 
performance  parameter.  As  seen  in  Figure  42,  the  FUWS  architecture  and  legacy 
architecture  are  no  longer  grouped,  with  the  FUWS  architecture  providing  significantly 
improved  performance  and  dominating  the  Pareto  Frontier. 
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Calculating  a  Technique  for  Order  of  Preference  by  Similarity  to  Ideal  Solution 
(TOPSIS)  score  for  each  alternative,  as  shown  in  equation  6  using  the  SIT,  indicates  the 
“best”  solutions  are  legacy  mine  solutions.  The  top  scores  are  for  the  legacy  solutions 
with  50  or  60  mines.  From  this  we  can  see  that  traditional  measures  of  performance 
would  bias  towards  the  legacy  solution  architecture. 


TOPSIS,  = 


(6) 


IkPP?  +LCCf  +fl -KPPy  +(\-KPPtf 


Where  KPPt  is  either  the  SIT  or  normalized  EC  of  the  /th  alternative  and 
LCCi  is  the  normalized  cost  of  the  z'th  alternative 

Calculating  TOPSIS  scores  using  the  normalized  EC  indicates  that  FUWS 
systems  provide  the  “best”  solutions.  As  discussed  earlier,  the  Mental  Focus  team 
considers  EC  a  more  relevant  operational  metric  that  should  be  considered  and 
emphasized  in  the  development  of  future  counter-mobility  capabilities. 
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VII.  CONCLUSION 


Modelers  can  give  instructions  to  hundreds  or  thousands  of  “agents”  all 
operating  independently.  This  makes  it  possible  to  explore  the  connection 
between  the  micro-level  behavior  of  individuals  and  the  macro-level 
patterns  that  emerge  from  their  interaction.  (Wilensky  2015) 

The  Mental  Focus  project  team  successfully  developed  a  system  architecture  and 
requirements  model  for  the  development  of  a  simulation  system,  consistent  with  the 
prime  objective  mission  statement  articulated  in  Chapter  I:  “Analyze  and  compare  system 
configurations  to  inform  the  development  and  employment  of  distributed  sensors  and 
networked  effectors  in  the  undersea  environment.”  By  developing  a  prototype  of  the 
required  simulation  system,  the  team  was  able  to  conduct  an  analysis  comparing  the 
performance  of  various  system  configurations  and  validating  the  conceptual  solution.  By 
answering  the  study  questions  developed  during  the  initial  project  proposal,  the  team  was 
able  to  demonstrate  the  success  of  the  project  and  identify  areas  for  future  study  and 
continued  development. 

A.  SUMMARY  OF  WORK 

Simulation  differs  from  standard  deduction  and  induction  in  both  its 
implementation  and  its  goals.  Simulation  permits  increased  understanding 
of  systems  through  controlled  computational  experiments.  (Axelrod  and 
Tesfatsion  2015) 

Using  a  combination  of  traditional  Systems  Engineering,  Model-Based  Systems 
Engineering,  and  Software  Engineering  practices,  the  project  team  analyzed  stakeholder 
needs,  established  mission  scenarios,  determined  functional  and  nonfunctional 
requirements,  developed  a  proposed  system  architecture  and  built  a  demonstration  model 
of  the  system. 
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1.  Study  Question  Answers 

1.  What  capabilities  does  a  networked  sensor-weapon  system  provide  over 
the  existing  legacy  mine  capability? 

The  team  employed  the  demonstration  model  to  address  this  question  in  Chapter 
VI.  The  team  was  able  to  show  that  FUWS  provides  a  potentially  significant 
improvement  in  EC  when  compared  with  legacy  capabilities  with  comparable  SIT 
performance  metrics.  While  the  predicted  SIT  was  similar  for  both  architectures,  the 
FUWS  minefield  presented  a  sustained  capability  to  subsequent  transiting  vessels  that  the 
legacy  systems  did  not.  This  threat  profile  prevents  the  enemy  from  forcing  a  channel 
through  the  minefield  with  a  few  sacrificial  ships.  While  counter-countermeasures,  such 
as  ship  counting  techniques,  could  be  used  to  “flatten”  the  legacy  threat  profile,  they  do 
this  by  shifting  the  threat  from  the  initial  transiting  vessel  to  subsequent  vessels.  To 
restore  the  SIT  and  achieve  the  EC  promised  by  the  FUWS  architecture  requires 
deploying  significantly  more  mines. 

2.  What  emergent  behavior  results  from  modular  networks  of  sensors  and 
weapons? 

The  team  employed  the  demonstration  model  to  address  this  question  in  Chapter 
VI.  Even  with  the  simple  model  used  in  the  demonstration,  the  team  was  able  to  highlight 
critical  system  behaviors  that  emerge  from  FUWS’s  distributed  network  of  sensors  and 
weapons.  The  planned  emergent  behavior  is  the  counter-mobility  capability  provided  by 
the  integration  of  sensors,  communicators  and  weapons  in  the  FUWS.  However,  the  most 
significant  unforeseen  emergent  behavior  is  the  change  in  the  threat  profile  predicted  in 
Chapter  VI. 

With  the  legacy  approach,  the  effectiveness  of  the  minefield  decays  as  additional 
vessels  enter  the  minefield.  As  the  enemy  forces  a  passable  channel  through  the 
minefield,  only  a  small  fraction  of  the  weapons  are  actually  employed  before  the  enemy’s 
movements  are  no  longer  restricted  and  the  counter-mobility  capability  is  lost.  This  is 
seen  in  the  exponential  decay  of  the  threat  profile  as  the  enemy  forces  through  the  area 
(Figure  38). 
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With  the  FUWS  approach,  the  effectiveness  of  the  minefield  is  maintained  as 
vessels  enter  the  minefield.  As  the  enemy  attempts  to  force  a  channel  through  the 
minefield,  a  significant  fraction  of  the  deployed  weapons  can  be  brought  to  bear, 
regardless  of  the  selected  path.  This  results  in  a  flatter,  if  not  truly  constant,  threat  profile. 
The  team  noted  that  a  second  order  polynomial  fit  could  describe  the  predicted  threat 
profile,  as  the  capability  would  begin  to  degrade  as  the  number  of  vessels  began  to 
approach  the  number  of  weapons  deployed.  While  the  minefield’s  predicted  threat  to  the 
first  vessel  was  similar  in  both  the  legacy  and  FUWS  minefields,  the  predicted  threat  to 
subsequent  vessels  was  significantly  higher  in  the  FUWS  approach.  This  threat,  of 
course,  begins  to  taper  as  the  number  of  vessels  approaches  the  number  of  weapons  in  the 
FUWS  and  collapses  when  the  number  of  weapons  is  exceeded.  The  FUWS  would  need 
to  be  re-enforced  to  maintain  the  capability,  much  as  a  minefield  would  need  to  be  re¬ 
seeded  to  reestablish  lost  capability. 

While  the  demonstration  prototype  makes  a  number  of  simplifying  assumptions, 
the  team  found  this  change  in  behavior  and  the  associated  improvement  in  predicted 
effectiveness  profound  enough  to  recommend  further  development  of  MFSA.  A  more 
robust  MFSA  simulation  system  would  provide  a  better  understanding  of  emergent 
behaviors,  support  understanding  of  the  system’s  performance  capabilities,  and  improve 
both  minefield  planning  and  the  development  of  future  minefield  capabilities. 

3.  What  are  the  necessary  sequences  of  events  that  must  be  modeled  in  a 
FUWS  architecture  to  simulate  mission  scenarios? 

The  project  team  chose  to  address  this  question  in  two  ways.  The  team  began  by 
constructing  use  cases  (Chapter  III)  that  would  assist  in  understanding  the  end-to-end 
sequence  of  events  from  data  input  to  information  output.  In  Chapter  V,  the  team  showed, 
using  sequence  diagrams,  the  necessary  sequence  of  events  that  would  be  required  for  the 
user  to  define  the  desired  FUWS  architecture  and  operational  scenario,  the  simulation  of 
the  architecture,  and  the  output  of  results  to  the  user.  The  team  also  acknowledged  that 
sequence  of  events  in  the  FUWS  detect-to-engage  sequence  could  be  decomposed  to 
various  levels  of  complexity.  As  such,  in  Chapter  III  the  team  identified  the  data 
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necessary  to  model  the  FUWS  architectures  at  basic,  intermediate  and  advanced  levels  of 
complexity  to  support  user  accuracy  requirements. 

The  team  also  addressed  this  question  by  developing  a  demonstration  prototype 
that  would  simulate  a  basic  mission  scenario.  This  aided  the  team  in  understanding  the 
expected  sequence  of  events  both  in  the  FUWS  and  in  the  MFSA  simulation  of  the 
FUWS.  The  team  was  able  to  use  the  process  of  prototype  system  development  to 
provide  feedback  to  requirement  identification  efforts  and  assist  in  requirement 
discovery. 

4.  What  parts,  if  any,  of  existing  models  or  simulation  systems  for  undersea 
warfare  could  be  reused  or  integrated  into  MFSA? 

In  the  early  phases  of  this  capstone  effort,  the  project  team  conducted  a  thorough 
literature  review  including  an  examination  of  current  advanced  mining  efforts  as  well  as 
current  modeling  and  simulation  efforts. 

As  described  in  Chapter  II,  the  team  reused  components  from  the  AUWS 
architecture  models  developed  by  the  SEA17B  Capstone  team  with  minor  changes  and 
adaptations.  The  Mental  Focus  project  team  used  this  instantiation  of  a  future  mining 
system  and  generalized  it  to  develop  the  FUWS  concept.  By  leveraging  the  SEA17B 
capstone  team’s  efforts,  the  Mental  Focus  team  was  able  focus  on  the  development  of 
MFSA.  This  supported  for  a  cohesive  continuation  of  study  on  the  topic  of  unmanned 
undersea  weapon  systems. 

The  team  also  identified  simulation  system  components  and  elements  for  reuse  in 
the  MFSA  simulation  system.  In  Chapter  V,  the  team  discussed  components  of  the  legacy 
system,  GAMET,  that  could  be  incorporated  in  the  MFSA  simulation  system.  These 
elements  include  features  of  the  graphical  user  interface,  the  sensor  and  communicator 
logic  parameters,  and  the  dual  user  modes.  Reusing  these  elements  allowed  the  team  to 
focus  the  System  Engineering  efforts  on  other  aspects  of  the  system  development. 
Ultimately,  the  team’s  analysis  of  GAMET  capabilities  and  weaknesses  was  instrumental 
in  the  development  of  a  cohesive  MFSA  conceptual  design. 
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2. 


Goals  Achieved 


1.  Apply  Model-Based  Systems  Engineering  (MBSE)  principles  to  the 
development  of  the  MFSA  architecture  conceptual  design. 

The  project  team  relied  heavily  on  MBSE  in  two  primary  lines  of  effort.  The  first 
was  the  use  of  Innoslate  to  develop  the  architectural  model  described  in  Chapter  V.  The 
second  was  the  use  of  NetLogo  and  Agent  Based  Modeling  to  develop  the  prototype 
model  described  in  Chapter  VI.  The  successful  application  of  MBSE  to  these  efforts 
enabled  the  accomplishment  of  subsequent  goals.  MBSE  allowed  the  project  team  to 
better  examine  the  functionality  of  the  system  and  understand  the  impacts  of  system 
elements  on  system  requirements. 

2.  Identify  requirements  for  the  MFSA  conceptual  architecture. 

The  project  team  identified  the  functional  requirements  (Chapter  III),  non¬ 
functional  requirements  (Chapter  IV),  and  developed  a  conceptual  architecture 
implementing  these  requirements  (Chapter  V).  In  the  functional  analysis,  the  team 
analyzed  the  purpose  of  the  system  and  required  outputs  that  would  support  fulfillment  of 
that  purpose.  The  team  then  developed  a  set  of  input  requirements  that  would  be  required 
to  produce  the  desired  outputs.  These  inputs,  described  in  more  detail  in  Appendix  C, 
provide  the  data  about  the  system  under  consideration  (the  sensors,  communicators  and 
effectors  that  comprise  the  weapon  system),  the  threat  and  the  environment  in  which  they 
operate.  With  these  inputs,  the  simulation  system  can  provide  the  user  with  the  required 
system  performance  information  to  support  alternative  design  and  operation  employment 
decisions. 

The  team  also  conducted  an  analysis  of  non-functional  requirements  that  would 
add  value  to  the  user  experience  and  support  the  functional  employment  of  the 
system.  Both  the  functional  and  nonfunctional  requirements  were  utilized  in  the 
development  of  the  proposed  conceptual  system  architecture. 

3.  Develop  model(s)  that  represent  the  sequence  of  targeting  and  decision 
events  in  a  mining  scenario  from  sensing  the  presence  of  a  vessel  to 
engaging  a  threat. 
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The  team  used  Innoslate  to  support  the  development  of  an  architectural  model  of 
the  proposed  MFSA  system  as  described  in  Chapter  V.  This  allowed  the  team  to  develop 
a  mature,  cohesive  system  architecture  model.  Innoslate  evaluates  the  maturity  based  on 
a  number  of  pass-fail  statements  in  five  different  categories:  Decomposition,  Traceability, 
Action  Performance,  Input/  Output  and  Connections. 
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Figure  43.  Innoslate  Model  Maturity  Tracker 


The  process  of  model  development  and  the  discipline  required  to  develop  a 
mature  architectural  model  aided  the  team  in  the  discovery  of  the  functional 
requirements.  As  seen  in  Chapter  V  and  Appendix  E,  the  process  of  developing  the 
functional  and  structural  architectures  helped  the  team  identify  requirements  not  directly 
linked  to  the  system  inputs  and  outputs. 

4.  Develop  a  prototype  simulation  system  to  demonstrate  the  conceptual 
architecture  and  to  support  requirement  discovery. 

The  project  team  developed  a  prototype  simulation  system  in  NetLogo  to 
demonstrate  the  conceptual  architecture  to  stakeholders  and  support  additional 
requirement  discovery.  The  team  defined  the  relationships  and  interactions  between 
sensors,  communicators,  weapons  and  the  threat  using  NetLogo’ s  Agent  Based  Modeling 
environment.  The  process  of  prototype  development  also  supported  the  requirement 
analysis  in  Chapters  III  and  V  and  the  identification  of  the  minimum  required  detect-to- 
engage  sequence  to  support  FUWS  simulation. 


While  the  team  made  a  number  of  simplifying  assumptions  to  support 
development  of  the  prototype  within  available  resources,  the  prototype  was  able  to 
demonstrate  the  detect-to-engage  sequence  of  a  FUWS  and  calculate  measures  of 
effectives  that  could  compare  various  FUWS  solution  approaches.  This  allowed  the  team 
to  conduct  analysis  in  Chapter  VI  comparing  the  performance  of  a  legacy  minefield  with 
that  of  a  FUWS,  showing  the  effectiveness  of  a  FUWS  architectural  approach  and  the 
potential  operational  and  cost  benefits  associated  with  the  FUWS  concept. 

5.  Investigate  which  measures  of  effectiveness  are  most  applicable  for 
evaluating  advanced  undersea  weapons  systems. 

The  team’s  initial  research  indicated  that  the  mine  warfare  community  relied 
excessively  on  Simple  Initial  Threat  (SIT)  measure  of  performance.  This  is  seen  in  the 
paucity  of  alternative  measures  of  performance  specified  for  minefield  planning  tasks 
(Appendix  B).  Reviews  of  doctrine  indicated  that,  while  other  established  measures  such 
as  expected  casualties  (EC)  and  the  threat  profile  were  available,  they  were  not 
emphasized  in  the  evaluation  of  plans  and  systems. 

The  team  postulated  that  these  other  MOPs  were  under  utilized  and  investigated 
their  applicability  to  the  FUWS  concept.  As  seen  in  Chapter  VI,  the  reliance  on  SIT  as  a 
single  measure  of  performance  is  viable  in  the  legacy  architecture  as  the  threat  profile  and 
EC  are  directly  related  to  the  SIT.  However,  the  team  also  showed  that  these  relationships 
change  when  the  architecture  is  changed  and  that  a  shift  in  emphasis  to  the  EC  in  a  design 
scenario  may  be  appropriate. 

The  team  recognized  that  a  system  such  as  MFSA  has  the  potential  to  leverage  the 
growth  in  available  computing  power  to  compute  additional,  potentially  new,  measures  of 
performance  and  effectiveness  and  provide  these  to  the  user  in  meaningful  ways.  As  seen 
in  Appendix  I,  the  team  postulated  that  the  minefield  effectiveness  is  not  uniform  and 
varies  across  the  minefield.  Providing  this  information  to  the  planner  can  ensure  that  the 
weapon  system  effectiveness  is  appropriately  distributed  by  the  placement  of  sensors  and 
weapons.  This  information  supports  improved  minefield  planning  and  informed 
operational  risk  decision-making  by  leadership. 
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B.  RECOMMENDATIONS  FOR  CONTINUED  DEVELOPMENT 

Within  the  scope  of  this  CAPSTONE  effort,  the  team  was  able  to  transition 
MFSA  into  the  conceptual  development  phase  of  the  system  life  cycle.  The  team 
demonstrated  Systems  Engineering,  Model-Based  Systems  Engineering,  and  Software 
Engineering  techniques  to  describe  the  system  context  and  the  proposed  solution  system 
at  a  high  level  of  abstraction.  The  expressed  need  for  a  MFSA  system  remains  (Ponirakis 
2014).  Further  Systems  Engineering  efforts  are  necessary  develop  and  deliver  an 
operational  MFSA  system.  The  project  team  recommends  that  continued  development 
efforts  focus  on  the  following  three  lines  of  effort:  comparison  of  alternative  MFSA 
system  architectures,  techniques  to  support  more  sophisticated  FUWS  targeting  logic 
options,  and  analysis  of  the  MFSA  integration  requirements  with  other  warfare  planning 
systems.  These  recommendations  represent  critical  System  Engineering  best  practices 
that  were  not  included  in  the  scope  of  this  project. 

The  Mental  Focus  team  developed  a  single  system  architecture  to  aid  in  the 
conceptual  understanding  of  the  proposed  software  system  and  in  the  development  of 
system  requirements.  However,  this  architecture  was  not  formally  evaluated  and  may  not 
be  the  most  successful  or  efficient  approach.  Before  transitioning  system  development  to 
the  detailed  design  phase,  a  formal  analysis  of  alternatives  should  be  performed  on 
comparative  system  architectures.  This  systems  engineering  analysis  should  use 
additional  stakeholder  input  and  priorities  to  develop  comparative  parameters  for  MFSA 
evaluation. 

The  targeting  logic  used  in  the  prototype  demonstration  is  very  simplistic.  The 
FUWS  modeled  simply  shoots  a  single  weapon  at  an  estimated  intercept  point  down  the 
expected  axis  of  motion  from  a  detecting  sensor.  Improvements  in  the  sophistication  of 
this  targeting  logic  could  dramatically  improve  the  system  performance.  Additionally, 
this  could  support  comparisons  of  alternative  strategies  such  as  limited  sensors  with  long 
ranges  developing  firing  solutions  based  on  changes  in  bearing  rate  vs  the  use  of  large 
numbers  of  short-range  sensors  developing  a  solution  by  tracking  sensor  activation 
history.  The  software  engineering  efforts  to  develop  targeting  logic  algorithms  could  be 
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incorporated  in  the  robust  menu  of  targeting  logics  required  in  an  operational  MFSA 
system. 

Finally,  the  team  recognized  an  opportunity  to  employ  MBSE  techniques  in  the 
integration  of  MFSA  into  a  larger  Systems  of  Systems.  While  this  integration  effort  was 
beyond  the  scope  of  this  capstone,  it  would  be  critical  to  the  successful  implementation  of 
a  MFSA  system.  The  capability  provided  by  a  MFSA  system  relies  on  integration  with 
appropriate  users,  other  warfare  planning  systems,  naval  doctrine,  policy,  and  logistics 
support.  This  integration  effort  must  articulate  the  value  of  MFSA  to  the  Navy’s  mission. 

These  lines  of  effort  would  support  transitioning  the  Mental  Focus  Simulation 
Application  to  the  next  step  in  the  system  life  cycle  and  inform  the  next  generation  of 
undersea  warfare  systems. 

C.  RECOMMENDATIONS  FOR  FUTURE  STUDY 

Recent  technological  advances  have  led  to  the  emergence  of  distributed 
wireless  sensor  and  actor  networks  (WSANs)  which  are  capable  of 
observing  the  physical  world,  processing  the  data,  making  decisions  based 
on  the  observations  and  performing  appropriate  actions.  (Akyildiz  and 
Kasimoglu  2004,  351) 

The  Mental  Focus  team  also  identified  three  areas  for  future  study.  WSANs  are  a 
class  of  systems,  analogous  to  the  FUWS  concept,  that  have  been  studied  over  the  past 
decade.  While  not  a  “wireless”  network,  the  FUWS  consists  of  sensors  and  actors 
(weapons)  as  nodes  in  a  weapon  system  network.  By  applying  the  understanding  gained 
in  the  study  of  WSAN  sensor-actor  coordination  and  actor-actor  coordination  to  the 
FUWS  system,  the  student  may  be  able  to  identify  requirements  that  support  robust  and 
fault  tolerant  FUWS  decision  algorithms. 

For  ad  hoc  sensor  networks,  routing  protocols  must  deal  with  some  unique 
constraints  such  as  limited  power,  low  bandwidth,  high  error  rate,  and 
dynamic  topology,  which  motivate  us  to  explore  routing  protocols  that  are 
energy  efficient,  self-adaptive,  and  error  tolerant.  (Wu  et  al.  2009,  282) 

This  leads  to  the  second  area  of  recommended  future  study,  ad  hoc  sensor 

networks.  Qishi  Wu  highlights  some  of  the  sensor  network  requirements  that  were  not 

explored  in  the  scope  of  this  project.  Specifically,  the  required  routing  protocols  that 
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support  sensor-sensor  and  sensor-actor  exchange  of  information  and  coordination.  The 
application  of  network  science  to  support  the  development  of  dynamic,  ad  hoc  network 
protocols  that  support  sensor  and  weapon  re-seeding  through  the  FUWS  deployment 
cycle  would  support  evaluation  of  FUWS  sustainability  requirements. 

A  primary  reason  for  the  popularity  of  ABM  and  its  departure  from  other 
simulation  paradigms  is  that  ABM  can  simulate  and  help  examine 
organized  complex  systems  (OCS).  This  means  the  ABM  paradigm  can 
represent  large  systems  consisting  of  many  subsystem  interactions.  (Heath 
etal.  2009) 

Finally,  the  ABM  technique  used  in  Chapter  VI  could  be  used  in  MBSE  analysis 
of  solution  architectures  and  approaches  in  other  warfare  systems.  For  example,  an  ABM 
model  could  be  used  to  show  how  an  air  and  missile  defense  system  capability  varies 
with  threat  axis  or  is  overwhelmed  by  a  particular  threat  scenario.  The  simple  simulations 
conducted  as  part  of  this  project  demonstrated  the  potential  power  of  this  approach, 
especially  when  integrating  large  quantities  of  similar  component  systems  or  when 
validating  autonomous  rule  sets  executed  by  sub-systems.  High  fidelity  Agent  Based 
Models  could  support  additional  detailed  trade  space  analysis  and  inform  detailed  design 
priorities. 
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APPENDIX  A:  FUWS  TASKS  AND  MEASURES 


The  Universal  Joint  Task  List  (UJTL)  and  Universal  Naval  Task  List  (UNTL)  are 
tools  used  for  articulating  mission  requirements  and  for  evaluating  mission  readiness 
(OPNAVINST  3500. 38B).  The  JCIDS  User  Manual  requires  capability  requirements  to 
be  traceable  to  universal  joint  tasks  (UJTs)  and  Service  tasks  (2015,  B-3).  This  appendix 
provides  a  summary  of  the  tasks  and  the  associated  measures  of  performance  (M#) 
identified  in  the  task  lists  that  are  traceable  to  mining  operations  and  to  FUWS 
capabilities.  From  the  descriptions  and  established  hierarchy,  one  can  see  that  mining 
capabilities  are  traceable  to  the  Counter-mobility  task  at  the  operational  and  strategic 
levels.  The  following  UJTs  are  quoted  from  the  UJTL  at  the  time  of  the  report.  Trailing 
citations  indicate  the  date  the  task  was  last  approved  or  modified  by  the  Director  of  the 
Joint  Staff. 

ST  1.5  Conduct  Counter  mobility.  Delay,  channel,  or  stop  offensive  air, 
land,  and  sea  movement  by  an  enemy  formation  attempting  to  achieve 
concentration  for  strategic  advantage. 

Notes:  This  task  may  include  actions  to  shape,  at  the  strategic  level, 
enemy  retrograde  operations  to  allow  friendly  exploitation. 


Ml 

Days 

Delay  an  enemy's  operations  and  movement  because  of  friendly 
systems  of  barriers,  obstacles,  and  mines. 

M2 

% 

Of  designated  forces  actually  assigned  to  monitor  and  enforce 
friendly  strategic  barriers  to  enemy  mobility. 

M3 

% 

Of  enemy  force  channeled  into  an  unfavorable  avenue  of  approach 
by  friendly  system  of  obstacles  or  barriers. 

M4 

% 

Reduction  in  enemy's  logistics  flow  (to  below  requirements  for 
offensive  action). 

(UJT  approved  06-MAR- 15) 


ST  1.5.1  Employ  Obstacles.  Channelize,  delay,  disrupt  or  reduce  the 
enemy  and  protect  friendly  forces  relative  to  employment  of  barriers, 
obstacles,  and  mines. 

Notes:  Before  hostilities,  barriers,  obstacles,  and  minefields  can  be  used  as 
flexible  deterrent  options  without  posing  an  offensive  threat.  Should 
deterrence  fail,  offensive  maritime  mining  of  enemy  ports  and  waters  can 
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constrict  enemy  seaborne  economic  war  sustainment  efforts  and  reduce 
enemy  ability  to  safely  deploy  maritime  forces.  Similarly,  offensive 
employment  of  scatterable  mines  can  deny  or  restrict  enemy  strategic 
mobility  and  sustainability  efforts.  Strategic  barriers,  obstacles,  and 
minefields  normally  are  emplaced  around  an  existing  terrain  feature  (e.g., 
mountain  chain  or  strait)  or  a  manmade  structure  (e.g.,  air  base,  canal, 
highway,  or  bridge).  Selecting  locations  and  emplacing  strategic  land  and 
maritime  obstacles  should  be  coordinated  among  multinational  forces 
(MNFs)  at  all  levels.  This  will  preclude  limiting  friendly  operational 
maneuver;  conflicting,  duplicative,  or  divergent  operations,  and  possible 
fratricide  among  MNF.  Plans  that  could  impact  on  other  theaters  should  be 
coordinated  to  prevent  potential  mutual  interference.  This  is  particularly 
important  for  maritime  minelaying  that  could  affect  strategic  movement  to 
or  from  other  theaters.  This  task  may  require  assessing  and  planning 
continuity  of  operations  (COOP)  or  mission-essential  tasks  provided 
specific  to  contractor  support  for  United  States  (US)  and  MNFs. 


Ml 

Days 

Delay  in  construction  of  strategic  systems  of  barriers,  obstacles,  and 

mines. 

M2 

% 

Of  locations  for  strategic  systems  of  barriers,  obstacles,  and  mines 
surveyed  before  crisis. 

M3 

% 

Of  systems  of  friendly  obstacles  and  barriers  successful  in  delaying, 
channeling,  or  stopping  enemy  offensive  action. 

(UJT  approved  01 -APR- 15) 


OP  1.4  Provide  Countermobility.  Conduct  countermobility  operations  to 
shape  enemy  maneuver  and  protect  friendly  forces. 

Notes:  Barrier,  obstacle,  and  mine  warfare  employment  is  not  an  end  in 
itself,  but  is  in  support  of  the  maneuver  plan  to  counter  the  enemys  [sic] 
freedom  of  maneuver.  This  task  may  include  support  to  enforcement  of 
sanctions,  embargoes,  blockades,  and  no-fly  zones. 


Ml 

% 

Enemy  avenues  of  approach  closed  as  maneuver  possibilities  by 
friendly  barriers,  obstacles,  or  mines. 

M2 

% 

Monthly  reduction  in  civil  populace  opinion  of  target  nation  central 
government. 

M3 

% 

Reduction  in  estimated  potential  enemy  course  of  action  (COAs) 
after  taking  counter-mobility  action 

M4 

% 

Of  reduction  in  target  nation  external  trade. 

M5 

% 

Of  reduction  in  target  nation  gross  domestic  product. 

(UJT  approved  17-AUG-15) 
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OP  1.4.1  Employ  System  of  Obstacles.  Restrict  enemy  maneuver  options 
or  create  friendly  maneuver  options. 

Notes:  This  task  may  include  the  use  of  coordinated  operational  and 
tactical  barriers  and  reinforcement  of  natural  obstacles.  Operational 
barriers  and  obstacles  may  be  created  by  the  composite  effect  of  many 
closely  coordinated  tactical  obstacles  or  by  the  reinforcement  of  natural 
obstacles  to  form  large  terrain  or  massive  obstacles.  Demolition  (obstacles 
are  created  by  detonation  of  explosives)  is  generally  used  to  create  tactical 
level  obstacles.  However,  it  can  also  be  used  to  create  operational 
obstacles  such  as  the  destruction  of  major  dams,  bridges,  and  railways,  as 
well  as  highways  through  built-up  areas  or  terrain  chokepoints. 
Constructed  obstacles  are  created  without  the  use  of  explosives  (examples 
are  barbed  wire  obstacles  and  tank  ditches).  Field  expedient  obstacles 
(abatis  or  flame  explosive)  can  provide  a  quick,  effective  means  for 
providing  a  limited  offensive  and  defensive  obstacle  capability  when 
conventional  resources  are  not  available. 


Ml 

% 

Of  increase  in  friendly  force  lines  of  communications  (LOCs)  after 
obstacle  emplacement. 

M2 

% 

Of  available  enemy  lines  of  communications  (LOCs)  and  ports  of 
debarkation  (PODs)  interdicted  by  friendly  obstacles. 

M3 

% 

Of  hostile  external  surface  communication  absorbed  by  other  lines 
of  communications  (LOCs)  after  barrier  emplacement. 

M4 

% 

Of  hostile  internal  surface  communication  absorbed  by  other  lines 
of  communications  (LOCs)  after  barrier  emplacement. 

M5 

% 

Of  reduction  in  hostile  military  surface  communications  after 
barrier  emplacement. 

M6 

% 

Of  reduction  in  hostile  overall  surface  communications  after  barrier 
emplacement. 

M7 

% 

Of  reduction  in  potential  enemy  course(s)  of  action  (COAs)  after 
obstacle  emplacement. 

M8 

Days 

Until  hostile  forces  are  unable  to  sustain  offensive  operations. 

M9 

% 

Of  increase  in  incidence  of  disease  in  target  nation  during 
quarantine  or  embargo. 

(UJT  approved  05-MAY-15) 


TA  1.4  Conduct  Mine  Operations.  Conduct  mining,  to  include  both  sea 
and  land  mines. 

Notes:  Mining  is:  1.  In  land  mine  warfare  —  an  explosive  or  material, 
normally  encased,  designed  to  destroy  or  damage  ground  vehicles,  boats, 
or  aircraft,  or  designed  to  wound,  kill,  or  otherwise  incapacitate  personnel. 
It  may  be  detonated  by  the  action  of  its  victim,  by  the  passage  of  time,  or 
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by  controlled  means.  2.  In  naval  mine  warfare  —  an  explosive  device  laid 
in  the  water  with  the  intention  of  damaging  or  sinking  ships  or  of  deterring 
shipping  from  entering  an  area.  The  term  does  not  include  devices 
attached  to  the  bottoms  of  ships  or  to  harbor  installations  by  personnel 
operating  underwater,  nor  does  it  include  devices  that  explode 
immediately  on  expiration  of  a  predetermined  time  after  laying.  May  be 
emplaced  by  land,  sea,  or  air  component  forces/  means. 


Ml  %_  Of  planned  mines  emplaced  in  accordance  with  the  operation  plan. 
(UJT  approved  12-MAY- 15) 


TA  1.4.1  Conduct  Offensive  Mine  Operations.  Conduct  the  offensive 
employment  of  mines. 

Notes:  Location  of  mines  employed  need  to  be  maintained  in  a  database 
that  can  facilitate  information  sharing  with  host  nation,  allies,  coalition, 
United  States  Government  agencies,  information  operations,  and 
nongovernmental  organizations  for  stability,  security,  transition,  and 
reconstruction  operations.  This  employment  is  not  an  end  in  itself,  but  is 
an  adjunct  to  other  military  capabilities.  To  conduct  the  offensive 
employment  of  mines  at  the  tactical  level  to  delay,  disrupt,  and  attrit 
enemy  forces  and  protect  friendly  forces.  Offensive  employment  of  mines 
can  deny  or  restrict  enemy  strategic  mobility  and  sustainability  efforts. 
Offensive  employment  of  mines  can  deny  or  restrict  enemy  strategic 
mobility  and  sustainability  efforts.  This  task  may  delay,  disrupt,  and  attrit 
enemy  forces  and  protect  friendly  forces. 


Ml 

Hours 

To  develop  plans  for  mine  placement  (land  and  maritime). 

M2 

Hours 

To  conduct  inventory  of  available  mine  types  and  quantity. 

M3 

Hours 

To  identify  available  maritime  mine  laying  capabilities. 

M4 

Hours 

To  identify  existing  mine  fields  (if  applicable). 

M5 

Hours 

To  identify  enemy  avenues  of  approach  and  retreat 

(UJT  approved  12-MAY- 15) 


TA  1.4.2  Conduct  Defensive  Mine  Operations.  Conduct  defensive  mine 
operations  to  degrade  the  enemys  [sic]  ability  to  maneuver,  destroy,  and 
attrit  the  enemy  force. 

Notes:  This  task  may  support  economy  of  force  measures;  and  to  retain 
key  terrain  or  areas  of  significant  tactical  value.  In  other  words,  adding 
depth  and  time  to  the  operational  environment  (OE).  Minefields  can 
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immobilize  and  canalize  enemy  forces  by  taking  advantage  of  terrain  by 
adding  strength  and  depth  to  the  OE. 


Ml 

% 

Of  planned  mines  emplaced  in  accordance  with  the  operation  plan. 

M2 

Y/N 

Was  guidance  provided  regarding  control  of  minefield  areas  and 
minefield  restricted  areas? 

(UJT  approved  12-MAY- 15) 


The  following  Service  tasks  are  quoted  from  the  UNTL. 


NTA  1.4  Conduct  Counter-mobility /To  construct  obstacles  and  employ 
area  denial  efforts  including  mines  to  delay,  disrupt,  and  destroy  the 
enemy.  The  primary  purpose  of  counter-mobility  operations  is  to  slow  or 
divert  the  enemy,  to  increase  time  for  target  acquisition,  and  to  increase 
weapons  effectiveness. 


Ml  Hours  Delay  m_enemy  force  movements  caused  by  mines/obstacles. 

M2  %  Of  enemy  forces  unable  to  reach  their  objective  due  to  obstacles. 

(UNTL  2007,  3  -B- 16) 


NTA  1.4.1  Conduct  Mining.  To  use  air,  ground,  surface,  and  subsurface 
assets  to  conduct  offensive  (deploy  mines  to  tactical  advantage  of  friendly 
forces)  and  defensive  (deploy  mines  for  protection  of  friendly  forces  and 
facilities)  mining  operations. 


Ml 

Days 

To  develop  obstacle/mining  plan. 

M2 

% 

Of  enemy  units  delayed  due  to  mining. 

M3 

% 

Of  enemy  units  damaged  or  destroyed  due  to  mining. 

(UNTL  2007,  3 -B- 16) 


NTA  3.2.1  Attack  Enemy  Maritime  Targets.  To  attack  sea  targets  with 
the  intent  to  degrade  the  ability  of  enemy  forces  to  conduct  coordinated 
operations  and/or  perform  critical  tasks.  This  task  includes  all  efforts  taken 
to  control  the  battlespace  by  warfare  commanders,  including  strikes 
against  high  payoff  and  high  value  targets,  such  as  missile  launching  ships 
and  submarines,  and  other  strike  and  power  projection  units  throughout 
the  theater.  This  task  includes  also  those  efforts  taken  to  undermine  the 
enemy’s  will  to  fight. 
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Ml 

% 

Of  attacking  systems  penetrate  to  target  to  deliver  ordnance. 

M2 

Mins 

After  target  identification  to  complete  attack. 

M3 

% 

Of  enemy  forces  destroyed,  delayed,  disrupted,  or  degraded. 

(UNTL  2007,  3-B-45) 
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APPENDIX  B:  MFSA  TASKS  AND  MEASURES 


This  appendix  provides  a  summary  of  the  UNTL  tasks  and  the  associated 
measures  of  performance  (M#)  that  are  traceable  to  the  tactical  capabilities  provided  by 
MFSA.  Note  that  the  quality  of  the  plan  is  measured  by  the  SIT  and  number  of  mines 
required.  The  following  Service  tasks  are  quoted  from  the  UNTL. 


NTA  1.4.1. 1  Plan  Minefields.  To  sequentially  develop  an  integrated  plan 
to  emplace  minefields  which  will  effectively  support  the  tactical  plan. 
Planning  consists  mainly  of  establishing  obstacle  restrictions  at  higher- 
level  units  and  detailed  design  and  citing  at  lower  level  units 


Ml 

Days 

To  develop  obstacle/mining  plan. 

M2 

# 

Mines  to  accomplish  minefields  objectives. 

(UNTL  2007,  3 -B- 16) 


NTA  5.4.3.6  Coordinate  Offensive  Mining  Operations.  To  coordinate 
offensive  mining  operations  to  neutralize  opposition  maritime  firepower 
and  minimize  threats  to  friendly  forces. 


Ml 

Hours 

To  coordinate  minefield  plan  and  input  to  MTO. 

M2 

Y/N 

Was  planned  minefield  effectiveness  achieved  at  >  50%  SIT? 

M3 

Y/N 

Was  minefield  re-seeding  considered? 

(UNTL  2007,  3-B-90) 
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APPENDIX  C:  MFSA  INPUT  REQUIREMENTS 


The  MFSA  simulation  system  fills  an  information  need  by  transforming  data 
describing  the  environment,  target,  and  weapon  system  into  relevant  outputs  describing 
the  weapon  system  performance.  To  develop  these  outputs,  MFSA  must  be  provided  with 
inputs  of  environmental,  target,  weapon  system,  and  mission  data.  This  appendix 
provides  additional  details  on  the  purpose  and  usage  of  the  inputs  requirements  identified 
in  Chapter  III.  In  particular  this  appendix  demonstrates  the  potential  effect  of  a  particular 
input  parameter  on  FUWS  performance,  and  thus  the  purpose  of  the  input  in  the  MFSA 
system.  Those  parameters  assigned  as  “basic”  are  necessary  to  the  development  of  a 
useful  performance  prediction,  those  designated  as  “intermediate”  or  “advanced”  will 
improve  the  MFSA  prediction  accuracy,  but  will  require  access  to  additional  data  and 
processing  power. 

ENVIRONMENTAL  INPUT  PARAMETERS 

Geographic  Boundaries:  According  to  the  International  Law,  the  locations  of 
mines  must  be  recorded  (Doswald-Beck  1995,  Art  83  and  84).  As  such,  minefield  should 
have  boundaries,  which  will  determine  the  area  of  coverage  necessary  and  thus  the 
number  of  weapons  required  to  achieve  the  desired  level  of  effect.  The  geographical 
boundaries  also  relate  to  several  other  characteristics  listed  below,  which  if  properly 
linked  to  authoritative  databases  could  automate  portions  of  the  input  process. 

Water  Depth:  While  minefields  are  often  visualized  in  two  dimensions,  the 
interactions  between  the  mines  and  targets  occur  in  three  dimensions.  Water  depth 
directly  impacts  the  performance  and  operation  of  sensors,  weapons,  communicators,  and 
target  vessels.  For  instance,  the  depth  of  explode-in-place  weapons  is  a  significant  factor 
in  the  damage  delivered  to  a  particular  target.  It  also  impacts  the  maneuverability  and 
detection  capability  of  mobile  weapons  such  as  torpedoes.  Shallow  water  can  pose 
challenges  to  acoustic  communicators  as  surface  and  bottom  reflections  complicate  the 
communication  signal  path.  The  movement  of  the  target  vessel  (particularly  submerged 
targets)  and  mobile  weapons,  such  as  torpedoes,  may  also  be  restricted  by  water  depth.  In 
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a  basic  scenario,  a  single  value,  such  as  average  water  depth,  may  be  adequate  to  describe 
performance,  in  more  advanced  scenarios  the  contours  of  a  bathymetric  profile  should  be 
used  to  increase  the  fidelity  of  the  simulation. 

Bathymetric  Profile:  As  described  above,  water  depth  is  a  critical  variable  for  a 
minefield  simulation  to  consider.  The  bathymetric  profile  provides  contours  of  the  sea 
floor,  allowing  better  understanding  of  how  individual  system  nodes  will  be  affected  by 
the  depth  at  their  location  and  by  the  potential  shadowing  of  signals  in  more  complex 
profiles. 

Sound  Velocity  Profile:  The  speed  at  which  sound  propagates  through  water 
varies  with  depth  (pressure)  and  is  a  function  of  a  number  of  environmental  factors  such 
as  water  temperature  and  salinity.  The  variations  in  sound  velocity  affect  the  path  of 
acoustic  signals  through  the  water  column  and  thus  the  performance  of  acoustic  sensors. 
In  deep  water,  this  can  be  significant  as  the  acoustic  signal  transmission  is  shaped  and 
ducted  or  isolated  by  changes  in  the  sound  velocity  profile. 

Current:  Strong  currents  will  affect  mobile  effectors,  such  as  torpedoes, 

introducing  a  source  of  error  in  both  aim  point  and  fuel  usage.  If  the  distance  from  the 
weapon  to  the  target  is  substantial,  the  fire  control  system  must  either  account  for  the 
current  or  risk  missing  the  target.  Additionally,  currents  can  impact  torpedo  fuel  usage, 
potentially  changes  the  effective  employment  range  of  a  weapon. 

Ambient  Noise  Level:  The  magnitude  of  background  acoustic  noise  in  the 
environment,  including  natural  (wind  and  biological  activity)  and  man-made  (shipping) 
sources,  can  interfere  with  or  obscure  signals  from  the  target  vessel  to  FUWS  acoustic 
sensors.  High  ambient  noise  level  could  also  degrade  the  effective  range  of  acoustic 
communications,  if  used. 

Ambient  Noise  Frequency  Range:  For  advanced  simulations,  in  which  detailed 
technical  data  is  available  for  relevant  system  and  environmental  parameters,  the 
frequency  range  of  ambient  noise  will  support  more  accurately  modeling  of  system 
performance.  For  instance,  low  frequency  ambient  noise  will  have  minimal  impacts  on 
high  frequency  acoustic  communicators  and  medium  frequency  threat  signals. 
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Seismic  Background  Noise:  Seismic  sensors  use  vibrations  of  the  seabed  to 
detect  the  proximity  of  vessels.  In  areas  with  significant  seismic  activity,  FUWS 
planners  and  developers  may  want  to  consider  the  effects  of  spurious  signals  generated 
by  natural  phenomena. 

Bottom  Type  /  Bottom  Loss:  Bottom  type  contributes  to  both  the  transmission  of 
acoustic  signals  (hard  sand  may  reflect  a  signal  that  is  absorbed  by  soft  mud)  and  the  self¬ 
burial  of  system  components. 

Fixed  Obstacles:  This  optional  input  serves  to  account  for  the  signal  shadowing 
of  known  obstacles,  such  as  oilrigs  or  wreckages,  that  could  impact  placement  and/or 
operation  of  FUWS  components. 

Probabilistic  Obstacles:  This  optional  input  would  allow  the  user  to  generate 
obstacles  based  on  an  estimated  probability  of  occurrence  for  a  given  region.  Examples  of 
such  probabilistic  obstacles  include  fishing  nets,  buoys,  and  biologies  that  could  degrade 
FUWS  performance  and  operation. 

TARGET  INPUT  PARAMETERS 

Number:  The  number  of  anticipated  targets  is  required  at  the  basic  level  to 
determine  the  threat  profile  (probability  that  nth  target  is  damaged).  In  advanced 
simulations,  the  user  may  want  to  configure  targeting  logic  based  on  the  ratio  of  weapons 
available  to  anticipated  targets,  conserving  weapons  for  high-value  or  particular  targets. 

Course:  The  course  describes  the  path  taken  by  targets  through  the  area,  and  thus 
the  opportunities  for  detection  and  engagement  by  the  weapon  system.  For  mobile 
weapons  the  course  of  the  target  affects  computation  of  the  fire  control  solution  and 
projected  intercept  point,  the  accuracy  of  which  directly  impact  the  success  of  the 
weapon. 

Speed:  The  speed  of  a  vessel  will  affect  the  acoustic  and  pressure  signals  it 
generates.  Also,  like  course,  the  speed  plays  a  significant  role  in  the  fire  control  solution 
and  projected  intercept  point  required  for  successful  employment  of  mobile  effectors. 
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Target  Priority:  When  the  number  of  weapons  is  limited,  it  may  be  desirable  to 
designate  high  value  targets  and  employ  an  advanced  targeting  logic.  For  example,  a  high 
priority  target  may  warrant  firing  a  two  shot  salvo  to  maximize  the  probability  of 
success.  Conversely,  a  low  priority  target  may  be  allowed  to  pass  by  if  higher  priority 
targets  are  detected  or  anticipated. 

Target  Mission:  The  counter-mobility  capability  attempts  to  deny  threat  vessels 
freedom  of  movement  in  or  through  an  area.  This  implies  that  the  threat  vessels  have  an 
operational  need  to  maneuver  to  a  destination.  The  axis  of  this  transit  or  assumed 
direction  of  travel  is  important  because  it  affects  the  optimal  orientation  of  the  sensors 
and  weapons.  In  general,  fewer  sensors/weapons  are  required  when  placed  in  a  pattern 
perpendicular  to  direction  of  travel  by  the  target. 

Class/Type:  The  class  of  target  vessel  can  be  linked  to  a  number  of  the  following 
characteristics,  supporting  automatic  population  of  appropriate  fields  from  recognized 
databases. 

Length:  To  cause  damage,  explosive  charges  must  be  detonated  in  close 
proximity  to  the  threat  vessel,  often  in  ranges  of  tens  to  low  hundreds  of  yards  from  the 
target.  As  such,  the  vessel  length,  which  can  be  over  a  hundred  yards,  can  be  a  significant 
factor  in  determining  both  the  damage  delivered  by  a  warhead  and  in  the  appropriate 
timing  of  weapon  engagement. 

Width  /  Beam:  For  an  explode-in-place  weapon,  the  vessel  width  can  be  a 
significant  characteristic  in  determining  the  damage  delivered  by  the  warhead.  In  mobile 
weapon  scenarios,  it  can  be  an  important  factor  in  determining  the  probability  of  a 
successful  engagement. 

Draft:  Vessel  draft  can  be  an  important  factor  in  the  determination  of  the  damage 
caused  by  explode-in-place  weapons.  It  is  also  a  significant  factor  in  determining  the 
susceptibility  of  a  vessel  to  active  acoustic  exploitation  by  active  sensors  and  active 
homing  devices  on  mobile  weapons.  Vessel  draft  also  determines  the  navigable  waters  in 
the  operating  area  and  the  mobility  of  the  target  in  shallow  water. 
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Max  Speed:  In  advanced  simulations,  the  user  may  desire  to  have  the  target 
vessel  attempt  to  evade  a  mobile  effector  by  accelerating  and  maneuvering.  The 
maximum  speed  would  provide  an  upper  boundary  to  ensure  the  target  vessel’s  ability  to 
evade  with  speed. 

Damage  Susceptibility:  This  input  provides  a  measure  of  the  targets 
susceptibility  to  various  weapons.  For  basic  simulations  an  average  or  stochastic 
susceptibility  may  be  applied  to  a  vessel.  Alternatively,  in  more  complex  analysis,  the 
susceptibility  may  be  a  function  of  the  area  of  the  ship,  allowing  the  simulation  to  model 
the  mission  impact  of  various  target  points. 

Hull  material:  Hull  material  may  be  related  to  the  magnetic  signature  of  the 
target  as  well  as  damage  susceptibility.  When  these  factors  are  unknown,  this  input 
allows  a  rough  estimation  of  characteristics  to  support  more  detailed  simulations. 

Displacement:  Magnetic  and  acoustic  signatures  can  be  positively  correlated  to 
the  displacement  of  a  ship.  When  these  signatures  are  unknown,  the  displacement  can 
provide  a  simple  proxy  for  estimating  them.  The  displacement  can  also  be  used  in 
conjunction  with  speed  and  water  depth  to  predict  the  pressure  signal.  Finally,  larger 
ships  tend  to  have  more  reserve  buoyancy,  and  thus  can  be  more  survivable. 

Magnetic  signature:  This  input  parameter  is  needed  to  simulate  the  target’s 
susceptibility  to  magnetic  sensors  in  both  legacy  mines  and  FUWS. 

Acoustic  signature:  The  acoustic  signature  as  a  function  of  speed  is  needed  to 
simulate  the  target’s  susceptibility  to  acoustic  and  seismic  sensors  in  both  legacy  mines 
and  FUWS.  The  acoustic  signature  could  include  the  frequency  distribution  in  order  to 
support  simulation  of  target  classification  in  advanced  scenarios. 

Maneuvering  tactics:  A  target  vessel  may  detect  and  maneuver  to  evade  an 
incoming  torpedo.  The  anticipated  maneuvering  tactics  of  the  adversary  will  influence 
the  lost  target  tactics  implemented  by  the  FUWS.  In  the  case  of  targets  with  better 
torpedo  detection  capabilities  and  maneuvering  characteristics,  the  timing  of  the 
engagement  may  become  critical  to  success. 
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Ship  Countermeasures:  Ships  may  employ  countermeasures  and  decoys  to 
mask  their  signals  and  disrupt  weapon  engagements.  In  more  advanced  simulations  these 
countermeasures  could  be  simulated  by  altering  ship  signatures  and  stochastically  causing 
false  returns  to  active  acoustic  sensors. 

Countermeasures  Tactics:  This  input  would  describe  the  tactics  an  adversary 
may  use  to  transit  the  minefield.  It  could  include  attempts  to  force  a  channel  through  the 
minefield,  route  and  speed  selection  based  on  bathymetric  information,  or  mine 
hunting/  sweeping. 

Mine  Hunting  Mission:  This  parameter  describes  the  probability  of  success  of 
mine  hunting  in  a  given  area  as  a  function  of  time.  This  could  be  used  by  the  simulation 
system  to  predict  the  expected  delay  required  by  the  adversary  to  clear  a  safe  passage 
route  and  to  determine  the  decay  of  counter-mobility  capability  performance  parameters 
over  time. 

Mine  Sweeping  Mission:  This  parameter  describes  the  probability  of  success  of 
mine  sweeping  a  given  area  as  a  function  of  time.  As  the  Mine  Hunting  Mission 
parameter,  this  input  could  be  used  by  the  simulation  system  to  predict  the  expected  delay 
required  by  the  adversary  to  clear  a  safe  passage  route  and  to  determine  the  decay  of 
counter-mobility  capability  performance  parameters  over  time. 

MISSION  INPUT  PARAMETERS 

Limited  Rules  of  Engagement:  Depending  on  the  phase  and  nature  of  the 
conflict,  the  rules  of  engagement  may  be  restricted.  For  example,  under  certain 
circumstances  the  FUWS  may  be  required  to  have  multiple  sensors  confirm  a  single 
target  to  ensure  it  is  a  valid  combatant.  In  other  cases,  the  system  may  be  allowed  to  fire 
on  any  transiting  vessel  based  on  a  single  data  source. 

Human  “in  loop”  required:  As  technology  advances  to  allow  greater  autonomy 
of  systems,  policy  decisions  may  be  imposed  that  require  a  human  to  decide  to  engage  a 
target.  The  latency  required  could  have  major  implications  on  a  FUWS  effectiveness  and 
this  mode  would  allow  those  effects  to  be  quantified. 
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Target  Discrimination  Required:  The  ability  to  simulate  the  capability  of  the 
FUWS  to  differentiate  between  various  types  of  potential  target  vessels  is  likely  to  be 
important  to  intermediate  and  advanced  simulations.  A  system’s  ability  to  discriminate 
between  types  of  targets  may  be  desired  to  reduce  risk  of  collateral  damage  to  non- 
combatants,  or  may  be  desired  to  reserve  weapons  for  the  highest  value  or  most 
susceptible  targets.  This  mode  of  simulation  would  allow  the  user  to  understand  how 
performance  changed  against  both  high-value  and  low-value  targets. 

FUWS  INPUT  PARAMETERS  (SENSORS) 

Number,  1  to  n:  The  quantity  of  a  particular  type  of  sensor  will  determine 
coverage  based  on  the  position  and  detection  range  of  each  sensor.  This  input  is  intended 
to  capture  each  sensor  node  or  unit,  which  may  be  comprised  of  multiple  sensors 
detecting  various  modalities. 

Position:  This  describes  the  geographical  position  of  a  particular  sensor  relative 
to  the  rest  of  the  field  and  is  necessary  for  calculation  detections  and  communication 
neighbors. 

Sensor  Type:  The  sensor  type  input  describes  the  identifying  characteristics  of  a 
particular  node  and  may  represent  a  package  of  sensors,  which  detect  multiple 
modalities.  The  aggregate  performance  of  this  sensor  is  described  by  additional  inputs. 

Probability  of  Detection  vs  Range:  For  simple  simulations,  or  where  sufficient 
data  is  not  available,  this  may  be  as  simple  as  a  single  range  with  a  probability  of 
detection.  More  accurate  simulations  would  use  a  table  of  probability  detections  at 
various  ranges. 

Bearing  Accuracy:  This  input  would  be  simulated  as  errors  in  the  bearing 
passed  from  sensors  would  support  simulation  of  the  errors  in  weapon  aim  points. 

Reliability:  Sensor  reliability  would  be  used  to  simulate  failure  rates  and  its 
impact  on  system  performance  in  more  advanced  simulation. 

Timing:  In  advanced  simulation,  precision  timing  information  could  be  used  to 
support  integration  of  data  from  multiple  sensors,  rapidly  localizing  the  threat  vessel. 
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Endurance/Power  Usage:  Energy  is  a  resource  consumed  by  every  action  of  the 
sensors.  Simple  simulation  may  assume  a  constant  value  or  to  time  to  energy 
exhaustion.  More  advanced  simulations  may  benefit  from  the  additional  detail  provided 
by  simulating  the  power  usage  to  process  a  contact  detection  and  the  consumption  based 
on  data  sampling  rate. 

FUWS  INPUT  PARAMETERS  (COMMUNICATORS) 

Range:  The  range  at  which  sensors  and  weapons  are  able  to  communicate  is 
critical  in  establishing  the  nodes  to  support  a  robust  network  architecture. 

Data  rate:  The  data  rate  limits  the  speed  of  communications  between  FUWS 
components  and  can  be  expected  to  impact  overall  system  performance. 

Latency:  This  input  describes  the  time  delay  at  each  node  required  to  send  and/or 
relay  a  message.  Combined  with  data  rate,  these  delays  can  be  used  to  simulate  the  age 
of  data  informing  the  targeting  logic. 

Reliability:  Sensor  reliability  would  be  used  to  simulate  failure  rates  and  its 
impact  on  system  performance  in  more  advanced  simulation.  The  effect  of  a 
communication  failure  on  the  overall  system  will  depend  on  the  particular  FUWS 
networked  architecture.  Robust  architectures  may  be  able  to  reroute  messages  around 
failed  communication  nodes.  Brittle  architectures  may  collapse  if  key  communication 
lines  fail. 

Endurance/Power  Usage:  Energy  is  a  resource  consumed  by  every 

transmission.  Simple  simulation  may  assume  a  constant  value  or  to  time  to  energy 
exhaustion.  More  advanced  simulations  will  benefit  from  the  additional  detail  provided 
by  simulating  the  power  usage  to  send  each  message. 

FUWS  INPUT  PARAMETERS  (WEAPONS) 

Number,  1  to  n:  The  number  of  weapons  not  only  establishes  the  number  of 
possible  engagements  and  overall  system  performance,  but  also  can  be  used  to  inform  the 
targeting  logic,  especially  when  attempting  to  focus  engagements  on  high-value  targets. 
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Weapon  Type:  The  type  of  weapon  selected  will  determine  some  of  the 
additional  fields  below  when  MFSA  is  able  to  pull  information  from  relevant 
databases.  There  may  be  multiple  weapon  types  within  a  FUWS  field. 

Position:  This  describes  the  geographical  position  of  a  particular  weapon  relative 
to  the  rest  of  the  field  and  is  necessary  for  calculation  of  communication  neighbors  and 
engagement  opportunities. 

UUV  Weapon  Batteries:  This  input  describes  how  mobile  weapons  are 
deployed  in  the  area.  The  UUV  may  be  as  simple  as  a  stationary  bottom  emplacement 
with  a  single  weapon  or  as  complex  as  a  large  diameter  UUV  patrolling  with  multiple 
torpedoes  onboard. 

Intercept  Speed:  This  input  describes  the  speed  of  the  weapon  when  attempting 
to  intercept  a  target.  Higher  search  speeds  reduce  the  time  of  the  engagement  but  can  also 
alert  the  target. 

Search  Speed:  This  input  describes  the  speed  of  the  weapon  as  it  searches  for  the 
target  in  primary  or  secondary  search  modes. 

Explosive  Power:  This  describes  the  ability  of  the  weapon  to  cause 
damage.  The  damage  transferred  to  the  vessel  is  a  function  of  the  explosive  power  of  the 
weapon,  the  relative  susceptibility  of  the  particular  vessel,  and  the  range  at  time  of 
detonation 

Fuel:  This  input  measures  the  energy  or  fuel  on  a  mobile  weapon  and  is  used  to 
determine  the  range 

Endurance:  This  input  is  used  to  describe  how  a  weapon  consumes  fuel  at 
various  speeds  and  search  patterns,  calculating  the  effective  weapon  range. 

Reliability:  Weapon  reliability  supports  simulation  of  weapon  failures  and  their 
impact  on  system  performance. 

Weapon  Search  Pattern:  MFSA  users  operators  may  seek  to  assess  the  impact 
of  different  weapon  primary  and  secondary  search  patterns  on  overall  system 
performance. 
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Targeting  Logic:  This  set  of  parameters  describes  the  decision  making  process 
used  to  determine  when  to  engage  and  where  to  aim  a  weapon.  The  targeting  logic  could 
also  include  limits  on  fire  control  solution  quality,  predicted  weapon  fuel  remaining, 
minimum  time  to  engagement,  and  other  ballistic  parameters. 
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APPENDIX  D:  UML  ARTIFACTS 


Figure  44.  User  Interfaces  with  MFSA 


Figure  44  shows  the  interactions  between  the  User  class  and  various  MFSA 
modules.  As  seen  here,  the  User  is  responsible  for  constructing  the  architecture  in  the 
Asset.  2.0  FUWS  Scenario  Architecture  Module ,  running  the  simulation  in  the  Asset.  3.0 
Simulation  Module  and  reading  and  interpreting  the  reports  provided  by  Asset.  4.0  Output 
Report  Module. 


Figure  45.  Software  Infrastructure  in  User  Mode 

Figure  45  shows  the  interactions  between  the  MFSA  Software  Infrastructure  and 
other  MFSA  modules  during  operation  by  the  User.  As  seen  here,  the  Software 
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Infrastructure  supports  the  other  modules  by  providing  the  user  interface  environment 
and  programming  backbone  required  by  the  various  MFSA  modules. 


Figure  46.  Decomposition  of  FUWS  Scenario  Architecture  Module 

Figure  46  shows  the  decomposition  of  the  FUWS  Scenario  Architecture  Module 
into  component  classes. 
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Figure  47.  Simulation  Module  Interfaces 


Figure  47  shows  the  interactions  between  the  Simulation  Module  and  other  MFSA 
modules.  As  seen  here,  the  Simulation  Module  inputs  are  provided  by  the  FUWS 
Scenario  Architecture  Module  and  outputs  are  provided  to  the  Output  Report  Module. 


Figure  48.  System  Administrator  Interfaces 


This  class  diagram  shows  the  interactions  between  the  System  Administrator  class 
and  various  MFSA  modules.  As  seen  here,  the  System  Administrator  is  responsible  for 
updating  and  maintaining  the  other  modules. 
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Infrastructure  Supports 


Figure  49.  MFSA  Software  Infrastructure  in  Maintenance  Mode 


This  class  diagram  shows  the  interactions  between  the  MFSA  Software 
Infrastructure  and  other  MFSA  modules  during  operation  by  the  System  Administrator. 
As  seen  here,  the  Software  Infrastructure  supports  the  other  modules  by  providing  the 
user  interface  environment  required  for  the  System  Administrator  to  access  the  various 
MFSA  modules. 
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APPENDIX  E:  MFSA  REQUIREMENT  TRACEABILITY 
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Figure  50.  Establish  Minefield  Architecture  Requirements 


Figure  50  shows  the  decomposition  of  Req.1.0  Establish  Minefield  Architecture 
and  traceability  of  the  requirement  to  system  actions  and  interfaces. 
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Figure  5 1 .  Output  Simulation  Data  Requirements 


Figure  51  shows  the  decomposition  of  Req.2.0  Output  Simulation  Data  and 
traceability  of  the  requirement  to  system  actions  and  interfaces. 
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Figure  52.  Run  Simulation  Requirements 


Figure  52  shows  the  decomposition  of  Req.3.0  Run  Simulation  and  traceability  of 
the  requirement  to  system  actions  and  interfaces. 
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Figure  53.  Update  System  Requirements 

Figure  53  shows  the  decomposition  of  Req.4.0  Update  by  System  Administrator 
and  traceability  of  the  requirement  to  system  actions  and  interfaces. 
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APPENDIX  F:  PROTOTYPE  TOOL  SELECTION 


Early  in  the  project  execution,  the  team  conducted  an  analysis  of  available 
simulation  environments  and  programming  languages  to  support  the  development  of  the 
MFSA  prototype.  The  team  considered  the  following  five  capability  requirements  when 
evaluating  each  available  simulation  tool: 

•  Functionality.  Does  the  tool  have  the  features  and  capabilities  necessary  to  model 
FUWS  architecture,  targeting  logic,  threat  scenarios  and  MOEs?  Does  the  tool 
have  the  desired  level  of  complexity? 

•  Accessibility.  Is  the  tool  available  for  team  use?  Are  there  licensing  concerns  or 
data  classification  concerns? 

•  Ease  of  Use/  Learning  Curve.  How  easy  is  it  to  build  a  model  in  the  tool  or  write 
the  code?  Are  there  helpful  tutorials  or  user  guides? 

•  Display  Graphical  Interface.  Does  the  tool  have  the  desired  display  output  to 
show  the  minefield  configuration  and  the  flow  of  threats  through  the  minefield? 

•  Collaborative  Ability.  How  easy  is  it  for  geographically  diverse  team  members  to 
work  collaboratively  on  building  the  model  while  maintaining  configuration 
control? 

The  team  performed  a  quick  pairwise  comparison  of  these  requirements  to 
determine  a  relative  weighting  factor  for  each.  As  seen  in  Figure  54,  accessibility  and 
functionality  were  considered  the  most  important  requirements  to  the  team.  The  team  was 
confident  that  their  collective  skills  and  experience  could  compensate  for  lack  of 
familiarity  with  the  selected  simulation  tool  (Ease  of  Use  /  Learning  Curve). 


Figure  54.  Pairwise  Comparison  of  Modeling  Tool  Requirements. 


The  project  team  considered  four  simulation  tools  as  backbones  for  development 


of  the  demonstration  prototype.  Requirement  scores  of  9  (provides  all,  or  nearly  all  of  the 
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required  capability),  3  (provides  some  of  the  required  capability),  1  (provides  very 
limited)  and  0  (provides  no  capability)  were  used  to  evaluate  each  system  against  each  of 
the  selection  requirements.  An  overall  suitability  score  for  each  tool  was  calculated  using 
the  sum-product  of  the  requirement  scores  and  requirement  weighting  factors  from  the 
pairwise  analysis.  As  seen  in  Figure  55,  Netlogo  was  ranked  as  the  best  tool  based  on  its 
high  evaluation  scores  on  functionality  and  accessibility. 


Relative 

Priority 

Nv  ModelingTools 

N.  (Hows) 

Team  n. 

Requirement 
(Whats)  Ns\ 

Microsoft  Excel 

Naval  Simulation 

System  (NSS) 

ExtendSim 

Net  Logo 

23.53% 

Functionality 

1 

9 

9 

9 

47.06% 

Accessibility 

9 

9 

9 

5.88% 

Ease  of  Use 
Learning  Curve 

9 

3 

3 

3 

11.76% 

Graphical  Interface/ 
Display 

1 

9 

1 

9 

11.76% 

Collaborative  Ability 

1 

1 

3 

Score 

Score% 

5.2353 

3.3529 

6.7647 

7.9412 

22.5% 

14.4% 

29.0% 

34.1% 

Figure  55.  Analysis  of  Modeling  Tools 


Also  of  note,  Netlogo  was  the  modeling  tool  with  the  highest  score  in 
collaborative  ability.  ExtenSim  ranked  second,  falling  slightly  short  of  NetLogo  in  almost 
all  evaluation  criteria.  Microsoft  Excel,  while  widely  accessible  and  easy  to  use,  did  not 
have  nearly  the  required  functionality  or  the  desired  display  interfaces  to  make  it  a  viable 
option.  Finally,  Naval  Simulation  System  (NSS)  promised  the  required  functionality,  but 
it  proved  to  be  very  difficult  for  the  team  to  gain  access  to  the  tool. 
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APPENDIX  G:  PROTOTYPE  DEMO 


The  Mental  Focus  prototype  demo  can  be  viewed  and  downloaded  from  the 
Netlogo  modeling  commons  at  http://modelingcommons.org/browse/one_model/4474. 

The  following  screenshots  from  the  demo  user  interface  are  used  to  explain  the 
interface  and  highlight  the  delivered  features. 

Figure  56  shows  a  FUWS  architecture  scenario.  Light  blue  circles  represent  the 
distributed  sensors  with  the  range  based  network  communications  paths  shown  in  grey. 
The  light  blue  exes  show  the  UUV  weapon  batteries.  The  red  lines  show  the  path 
histories  taken  by  hostile  ships  transiting  the  area,  allowing  the  user  to  visualize  the  tactic 
used  by  the  threat  ships. 
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Figure  56.  MFSA  Demo  -  FUWS 
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Figure  57  shows  a  legacy  architecture  scenario.  The  interface  remains  the  same, 
as  do  many  of  the  graphics.  However,  one  can  see  that  the  sensors  and  UUV  weapon 
batteries  are  replaced  by  light  blue  circles  with  exes  show  the  mines.  Additionally,  there 
are  no  communication  paths  between  the  mines,  and  thus  no  network. 
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Figure  57.  MFSA  Demo  -  Legacy 
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APPENDIX  H:  PROTOTYPE  SIMULATION  RESULTS 


This  appendix  provides  the  summary  statistics,  including  box  plots  of  the  SIT  and 
EC  results  for  the  Monte  Carlo  simulations  discussed  in  Chapter  VI.  As  in  Chapter  VI, 
the  legacy  results  are  highlighted  in  blue  and  the  FUWS  results  in  green  to  provide  visual 
discrimination  between  the  graphs  and  tables. 

Figures  58  and  59  show  the  performance  of  legacy  systems  as  a  function  of  the 
number  of  mines  deployed.  For  each  number  of  mines,  there  are  two  data  points,  one  for 
each  number  of  minelines  considered.  Note  that  as  the  number  of  mines  is  increased,  the 
performance  (SIT  or  EC)  increases  as  well. 

Figures  60  and  61  similarly  show  the  performance  of  FUWS  architectures  as  a 
function  of  the  number  of  UUV  batteries  to  which  the  mobile  weapons  (torpedoes)  are 
deployed.  For  each  number  of  UUV  batteries,  there  are  four  data  points  corresponding  to 
the  number  of  sensors  and  sensor  lines  considered.  In  general,  for  a  given  UUV 
configuration,  increasing  the  number  of  sensors  and  the  number  of  sensor  lines  tends  to 
increase  performance.  Increasing  the  number  of  UUVs  does  not  appear  to  appreciably 
impact  the  system  performance.  However,  one  should  also  note  the  significantly  larger 
variation  shown  in  the  box  plots  for  the  FUWS  systems.  Improving  the  deployment 
algorithm  to  ensure  UUV’s  are  within  range  of  the  sensor  network(s)  and  improving  the 
target  logic  should  reduce  the  variation  in  the  FUWS  system  performance. 
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LEGACY  RESULTS 


Number  of  Mines 


Figure  58.  Boxplot:  SIT  versus  Number  of  Mines 


Figure  59.  Boxplot:  EC  versus  Number  of  Mines 
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Table  16.  Summary  Statistics  50  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

T5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.195 

0.494 

0.298 

0.175 

0.099 

0.071 

0.058 

-Ttrim 

1.165 

0.495 

0.320 

0.175 

0.090 

0.070 

0.060 

s2 

0.008 

0.001 

0.004 

0.002 

0.000 

0.000 

0.001 

S 

0.084 

0.031 

0.060 

0.040 

0.021 

0.020 

0.024 

cv 

0.070 

0.063 

0.200 

0.229 

0.209 

0.278 

0.421 

^max 

1.33 

0.55 

0.39 

0.23 

0.14 

0.12 

0.10 

x75% 

1.26 

0.52 

0.33 

0.21 

0.11 

0.08 

0.07 

x50% 

1.17 

0.50 

0.32 

0.18 

0.09 

0.07 

0.06 

x25% 

1.14 

0.48 

0.27 

0.14 

0.09 

0.06 

0.04 

xmin 

1.10 

0.44 

0.16 

0.12 

0.07 

0.04 

0.02 

Table  17.  Summary  Statistics  50  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.231 

0.502 

0.304 

0.182 

0.101 

0.078 

0.064 

-Ttrim 

1.200 

0.495 

0.305 

0.160 

0.110 

0.080 

0.060 

s2 

0.013 

0.002 

0.001 

0.002 

0.001 

0.001 

0.001 

S 

0.110 

0.042 

0.035 

0.044 

0.029 

0.023 

0.025 

CV 

0.090 

0.083 

0.116 

0.243 

0.292 

0.297 

0.390 

Xmax 

1.49 

0.59 

0.36 

0.28 

0.13 

0.14 

0.11 

X75% 

1.30 

0.53 

0.33 

0.19 

0.13 

0.08 

0.08 

X50% 

1.20 

0.50 

0.31 

0.16 

0.11 

0.08 

0.06 

X25% 

1.15 

0.48 

0.28 

0.15 

0.08 

0.06 

0.06 

xmin 

1.11 

0.44 

0.25 

0.15 

0.04 

0.05 

0.02 

Table  18.  Summary  Statistics  60  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

T6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.401 

0.559 

0.348 

0.200 

0.136 

0.092 

0.066 

'Ttrim 

1.385 

0.560 

0.330 

0.190 

0.140 

0.095 

0.055 

s2 

0.011 

0.003 

0.003 

0.002 

0.001 

0.001 

0.001 

S 

0.098 

0.055 

0.054 

0.040 

0.035 

0.034 

0.030 

CV 

0.070 

0.098 

0.154 

0.202 

0.259 

0.373 

0.456 

Xmax 

1.60 

0.63 

0.43 

0.27 

0.20 

0.17 

0.11 

X75% 

1.47 

0.61 

0.40 

0.23 

0.16 

0.10 

0.10 

x50% 

1.39 

0.56 

0.33 

0.19 

0.14 

0.10 

0.06 

X25% 

1.32 

0.51 

0.32 

0.17 

0.10 

0.07 

0.04 

xmin 

1.27 

0.48 

0.28 

0.15 

0.09 

0.04 

0.03 
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Table  19.  Summary  Statistics  60  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.412 

0.544 

0.339 

0.227 

0.152 

0.075 

0.075 

-Ttrim 

1.415 

0.555 

0.335 

0.220 

0.155 

0.075 

0.075 

s2 

0.014 

0.001 

0.002 

0.002 

0.001 

0.001 

0.001 

S 

0.114 

0.036 

0.047 

0.039 

0.021 

0.022 

0.025 

cv 

0.080 

0.066 

0.140 

0.172 

0.140 

0.288 

0.333 

^max 

1.63 

0.58 

0.42 

0.33 

0.18 

0.11 

0.11 

x75% 

1.44 

0.57 

0.38 

0.23 

0.17 

0.09 

0.10 

x50% 

1.42 

0.56 

0.34 

0.22 

0.16 

0.08 

0.08 

x25% 

1.40 

0.54 

0.30 

0.21 

0.14 

0.06 

0.06 

xmin 

1.20 

0.46 

0.27 

0.17 

0.10 

0.04 

0.03 

Table  20.  Summary  Statistics  70  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.590 

0.611 

0.376 

0.239 

0.162 

0.123 

0.079 

-Ttrim 

1.605 

0.605 

0.380 

0.230 

0.180 

0.120 

0.080 

s2 

0.011 

0.002 

0.002 

0.002 

0.001 

0.001 

0.000 

s 

0.101 

0.040 

0.045 

0.040 

0.035 

0.030 

0.018 

cv 

0.064 

0.065 

0.121 

0.169 

0.215 

0.247 

0.230 

Xmax 

1.73 

0.69 

0.43 

0.30 

0.20 

0.17 

0.11 

X75% 

1.68 

0.62 

0.42 

0.28 

0.19 

0.15 

0.09 

X50% 

1.61 

0.61 

0.38 

0.23 

0.18 

0.12 

0.08 

X25% 

1.49 

0.59 

0.34 

0.21 

0.12 

0.11 

0.07 

xmin 

1.45 

0.56 

0.29 

0.17 

0.12 

0.06 

0.04 

Table  21.  Summary  Statistics  70  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.717 

0.656 

0.415 

0.262 

0.175 

0.121 

0.088 

1.740 

0.665 

0.425 

0.270 

0.185 

0.115 

0.070 

s2 

0.010 

0.002 

0.004 

0.001 

0.001 

0.001 

0.001 

S 

0.095 

0.047 

0.059 

0.033 

0.032 

0.024 

0.029 

CV 

0.055 

0.072 

0.143 

0.125 

0.183 

0.197 

0.325 

Xmax 

1.85 

0.73 

0.52 

0.30 

0.21 

0.18 

0.14 

X75% 

1.75 

0.69 

0.44 

0.29 

0.20 

0.13 

0.11 

x50% 

1.74 

0.67 

0.43 

0.27 

0.19 

0.12 

0.07 

X25% 

1.67 

0.63 

0.38 

0.24 

0.15 

0.11 

0.07 

xmin 

1.51 

0.55 

0.30 

0.21 

0.12 

0.09 

0.05 
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Table  22.  Summary  Statistics  80  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.826 

0.656 

0.461 

0.277 

0.204 

0.122 

0.106 

-Ttrim 

1.820 

0.660 

0.460 

0.275 

0.215 

0.120 

0.110 

s2 

0.013 

0.002 

0.003 

0.001 

0.003 

0.001 

0.000 

S 

0.110 

0.045 

0.049 

0.033 

0.049 

0.026 

0.019 

cv 

0.060 

0.068 

0.106 

0.120 

0.241 

0.213 

0.180 

^max 

2.00 

0.73 

0.56 

0.35 

0.26 

0.18 

0.14 

x75% 

1.90 

0.69 

0.49 

0.29 

0.24 

0.13 

0.12 

x50% 

1.82 

0.66 

0.46 

0.28 

0.22 

0.12 

0.11 

x25% 

1.74 

0.63 

0.43 

0.26 

0.18 

0.11 

0.09 

xmin 

1.66 

0.58 

0.39 

0.23 

0.09 

0.08 

0.08 

Table  23.  Summary  Statistics  80  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

1.899 

0.651 

0.474 

0.303 

0.193 

0.153 

0.125 

-Ttrim 

1.850 

0.640 

0.485 

0.295 

0.190 

0.160 

0.140 

s2 

0.011 

0.000 

0.001 

0.002 

0.002 

0.002 

0.001 

S 

0.098 

0.021 

0.037 

0.047 

0.039 

0.047 

0.035 

CV 

0.052 

0.032 

0.077 

0.154 

0.201 

0.307 

0.280 

Xmax 

2.13 

0.69 

0.51 

0.39 

0.25 

0.23 

0.16 

X75% 

1.95 

0.67 

0.51 

0.33 

0.23 

0.18 

0.15 

X50% 

1.85 

0.64 

0.49 

0.30 

0.19 

0.16 

0.14 

X25% 

1.83 

0.63 

0.45 

0.26 

0.16 

0.14 

0.10 

xmin 

1.81 

0.63 

0.40 

0.25 

0.14 

0.07 

0.06 

Table  24.  Summary  Statistics  90  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

2.004 

0.691 

0.497 

0.339 

0.219 

0.143 

0.115 

'Ttrim 

2.000 

0.710 

0.500 

0.340 

0.220 

0.140 

0.115 

s2 

0.018 

0.004 

0.002 

0.002 

0.001 

0.001 

0.001 

S 

0.126 

0.057 

0.043 

0.041 

0.036 

0.032 

0.028 

CV 

0.063 

0.082 

0.086 

0.120 

0.166 

0.223 

0.247 

Xmax 

2.16 

0.76 

0.55 

0.39 

0.26 

0.19 

0.16 

X75% 

2.13 

0.74 

0.54 

0.38 

0.26 

0.17 

0.13 

x50% 

2.00 

0.71 

0.50 

0.34 

0.22 

0.14 

0.12 

X25% 

1.90 

0.65 

0.47 

0.33 

0.19 

0.12 

0.09 

xmin 

1.81 

0.59 

0.41 

0.26 

0.16 

0.09 

0.08 
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Table  25.  Summary  Statistics  90  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

2.111 

0.699 

0.527 

0.361 

0.228 

0.174 

0.122 

-Ttrim 

2.065 

0.690 

0.530 

0.355 

0.240 

0.165 

0.125 

s2 

0.023 

0.002 

0.002 

0.003 

0.003 

0.001 

0.000 

S 

0.145 

0.041 

0.040 

0.048 

0.049 

0.026 

0.017 

cv 

0.069 

0.058 

0.076 

0.132 

0.214 

0.150 

0.136 

^max 

2.38 

0.78 

0.58 

0.46 

0.31 

0.23 

0.15 

x75% 

2.19 

0.72 

0.56 

0.40 

0.26 

0.18 

0.13 

x50% 

2.07 

0.69 

0.53 

0.36 

0.24 

0.17 

0.13 

x25% 

2.02 

0.67 

0.51 

0.32 

0.18 

0.16 

0.11 

xmin 

1.90 

0.65 

0.45 

0.30 

0.15 

0.14 

0.10 

Table  26.  Summary  Statistics  100  Mines  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

Ts 

t6 

N 

10 

10 

10 

10 

10 

10 

10 

X 

2.188 

0.776 

0.525 

0.365 

0.242 

0.150 

0.130 

-Ttrim 

2.165 

0.785 

0.520 

0.370 

0.260 

0.145 

0.140 

s2 

0.014 

0.002 

0.006 

0.001 

0.002 

0.001 

0.001 

s 

0.114 

0.041 

0.075 

0.034 

0.037 

0.035 

0.028 

cv 

0.052 

0.052 

0.142 

0.093 

0.152 

0.237 

0.212 

Xmax 

2.43 

0.85 

0.64 

0.42 

0.28 

0.21 

0.16 

X75% 

2.20 

0.80 

0.58 

0.39 

0.27 

0.18 

0.16 

X50% 

2.17 

0.79 

0.52 

0.37 

0.26 

0.15 

0.14 

X25% 

2.13 

0.74 

0.48 

0.35 

0.22 

0.12 

0.11 

xmin 

2.00 

0.72 

0.41 

0.29 

0.17 

0.11 

0.08 

Table  27.  Summary  Statistics  100  Mines  in  10  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

10 

10 

10 

10 

10 

10 

10 

X 

2.250 

0.749 

0.559 

0.372 

0.258 

0.175 

0.137 

2.240 

0.750 

0.545 

0.360 

0.260 

0.185 

0.140 

s2 

0.011 

0.002 

0.002 

0.002 

0.002 

0.001 

0.002 

S 

0.099 

0.041 

0.043 

0.039 

0.039 

0.035 

0.037 

CV 

0.044 

0.055 

0.077 

0.104 

0.150 

0.202 

0.273 

Xmax 

2.45 

0.82 

0.64 

0.45 

0.32 

0.23 

0.20 

X75% 

2.32 

0.77 

0.59 

0.39 

0.29 

0.19 

0.15 

x50% 

2.24 

0.75 

0.55 

0.36 

0.26 

0.19 

0.14 

X25% 

2.17 

0.72 

0.54 

0.35 

0.23 

0.15 

0.11 

xmin 

2.11 

0.69 

0.49 

0.31 

0.20 

0.11 

0.08 
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FUWS  RESULTS 


Number  of  UUVs 


Figure  60.  Boxplot:  SIT  versus  Number  of  Mines 


Figure  61 .  Boxplot:  EC  versus  Number  of  Mines 


129 


Table  28.  Summary  Statistics  1  UUV  and  50  Sensors  in  2  Lines 


EC 

SIT 

T  2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

2.465 

0.421 

0.421 

0.414 

0.415 

0.419 

0.377 

2.370 

0.403 

0.415 

0.400 

0.405 

0.410 

0.360 

s2 

0.100 

0.005 

0.002 

0.003 

0.003 

0.003 

0.003 

S 

0.308 

0.067 

0.057 

0.056 

0.056 

0.050 

0.057 

cv 

0.125 

0.159 

0.135 

0.134 

0.134 

0.118 

0.151 

^max 

3.25 

0.60 

0.56 

0.54 

0.57 

0.55 

0.50 

x75% 

2.59 

0.44 

0.43 

0.45 

0.44 

0.42 

0.41 

x50% 

2.38 

0.40 

0.42 

0.40 

0.41 

0.41 

0.36 

x25% 

2.26 

0.39 

0.39 

0.39 

0.39 

0.38 

0.33 

xmin 

2.07 

0.34 

0.33 

0.31 

0.33 

0.35 

0.30 

Table  29.  Summary  Statistics  1  UUV  and  50  Sensors  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

2.930 

0.494 

0.504 

0.486 

0.493 

0.494 

0.459 

-Ttrim 

2.940 

0.493 

0.518 

0.485 

0.485 

0.490 

0.445 

s2 

0.136 

0.005 

0.003 

0.005 

0.004 

0.005 

0.003 

S 

0.360 

0.071 

0.067 

0.066 

0.061 

0.071 

0.056 

CV 

0.123 

0.143 

0.133 

0.135 

0.124 

0.143 

0.123 

Xmax 

3.94 

0.70 

0.68 

0.64 

0.65 

0.68 

0.59 

X75% 

3.07 

0.53 

0.53 

0.53 

0.53 

0.54 

0.48 

X50% 

2.94 

0.49 

0.52 

0.49 

0.49 

0.49 

0.45 

X25% 

2.68 

0.45 

0.46 

0.45 

0.45 

0.44 

0.42 

xmin 

2.32 

0.38 

0.38 

0.38 

0.41 

0.36 

0.39 

Table  30.  Summary  Statistics  1  UUV  and  100  Sensors  in  2  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.120 

0.535 

0.526 

0.534 

0.526 

0.524 

0.476 

“Ttrim 

3.105 

0.533 

0.528 

0.530 

0.528 

0.528 

0.473 

s2 

0.081 

0.003 

0.003 

0.003 

0.003 

0.002 

0.004 

s 

0.278 

0.055 

0.040 

0.057 

0.050 

0.044 

0.065 

cv 

0.089 

0.103 

0.075 

0.107 

0.094 

0.083 

0.137 

Xmax 

3.73 

0.65 

0.63 

0.64 

0.62 

0.60 

0.62 

X75% 

3.32 

0.59 

0.54 

0.58 

0.55 

0.55 

0.51 

x50% 

3.10 

0.54 

0.53 

0.53 

0.53 

0.53 

0.48 

X25% 

2.95 

0.50 

0.51 

0.51 

0.49 

0.51 

0.44 

xmin 

2.55 

0.43 

0.45 

0.42 

0.43 

0.40 

0.37 
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Table  31.  Summary  Statistics  1  UUV  and  100  Sensors  in  5  Lines 


EC 

SIT 

T  2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.507 

0.598 

0.604 

0.596 

0.585 

0.577 

0.547 

3.693 

0.633 

0.630 

0.620 

0.613 

0.588 

0.583 

s2 

0.348 

0.011 

0.004 

0.010 

0.010 

0.009 

0.011 

S 

0.575 

0.102 

0.105 

0.095 

0.100 

0.090 

0.102 

cv 

0.164 

0.171 

0.174 

0.159 

0.170 

0.157 

0.186 

^max 

4.38 

0.73 

0.75 

0.78 

0.77 

0.71 

0.68 

x75% 

3.92 

0.67 

0.67 

0.66 

0.65 

0.65 

0.62 

x50% 

3.70 

0.64 

0.64 

0.62 

0.61 

0.59 

0.59 

x25% 

3.21 

0.54 

0.58 

0.55 

0.52 

0.52 

0.51 

xmin 

2.30 

0.37 

0.38 

0.42 

0.38 

0.37 

0.34 

Table  32.  Summary  Statistics  2  UUV  and  50  Sensors  in  2  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

N 

20 

20 

20 

20 

20 

20 

20 

X 

2.644 

0.456 

0.447 

0.469 

0.440 

0.445 

0.388 

-Ttrim 

2.520 

0.438 

0.428 

0.453 

0.423 

0.428 

0.383 

s2 

0.301 

0.010 

0.002 

0.008 

0.010 

0.009 

0.008 

S 

0.534 

0.097 

0.098 

0.089 

0.098 

0.090 

0.088 

CV 

0.202 

0.213 

0.220 

0.189 

0.224 

0.202 

0.226 

Xmax 

4.12 

0.72 

0.70 

0.70 

0.68 

0.70 

0.62 

X75% 

2.83 

0.47 

0.48 

0.49 

0.47 

0.49 

0.41 

X50% 

2.52 

0.44 

0.43 

0.45 

0.42 

0.43 

0.39 

X25% 

2.29 

0.39 

0.38 

0.42 

0.38 

0.37 

0.34 

xmin 

2.01 

0.35 

0.30 

0.36 

0.29 

0.34 

0.25 

Table  33.  Summary  Statistics  2  UUV  and  50  Sensors  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

N 

20 

20 

20 

20 

20 

20 

20 

X 

3.025 

0.530 

0.514 

0.517 

0.508 

0.510 

0.446 

“Ttrim 

3.028 

0.520 

0.510 

0.525 

0.510 

0.500 

0.450 

s2 

0.064 

0.005 

0.003 

0.004 

0.002 

0.003 

0.002 

s 

0.246 

0.067 

0.056 

0.063 

0.047 

0.052 

0.042 

cv 

0.081 

0.126 

0.109 

0.122 

0.092 

0.102 

0.094 

Xmax 

3.52 

0.63 

0.64 

0.62 

0.60 

0.61 

0.53 

X75% 

3.18 

0.60 

0.55 

0.57 

0.54 

0.54 

0.47 

x50% 

3.05 

0.52 

0.51 

0.52 

0.51 

0.50 

0.45 

X25% 

2.83 

0.49 

0.48 

0.47 

0.48 

0.47 

0.43 

xmin 

2.49 

0.42 

0.41 

0.39 

0.41 

0.43 

0.37 

131 


Table  34.  Summary  Statistics  2  UUV  and  100  Sensors  in  2  Lines 


EC 

SIT 

T  2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.264 

0.562 

0.569 

0.576 

0.558 

0.529 

0.472 

3.318 

0.583 

0.578 

0.590 

0.553 

0.535 

0.485 

s2 

0.120 

0.005 

0.003 

0.003 

0.003 

0.003 

0.005 

S 

0.338 

0.068 

0.073 

0.055 

0.057 

0.055 

0.066 

cv 

0.103 

0.121 

0.129 

0.096 

0.102 

0.104 

0.140 

^max 

3.63 

0.65 

0.68 

0.64 

0.66 

0.62 

0.56 

x75% 

3.51 

0.62 

0.60 

0.61 

0.59 

0.56 

0.52 

x50% 

3.30 

0.58 

0.58 

0.59 

0.55 

0.54 

0.49 

x25% 

3.08 

0.51 

0.55 

0.56 

0.53 

0.51 

0.43 

xmin 

2.13 

0.38 

0.33 

0.40 

0.40 

0.34 

0.28 

Table  35.  Summary  Statistics  2  UUV  and  100  Sensors  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.818 

0.669 

0.683 

0.672 

0.642 

0.612 

0.541 

-Ttrim 

3.980 

0.710 

0.708 

0.698 

0.673 

0.625 

0.563 

s2 

0.316 

0.013 

0.005 

0.011 

0.010 

0.006 

0.008 

S 

0.548 

0.109 

0.103 

0.100 

0.096 

0.077 

0.086 

CV 

0.144 

0.164 

0.151 

0.150 

0.149 

0.126 

0.159 

Xmax 

4.42 

0.77 

0.81 

0.77 

0.78 

0.70 

0.67 

X75% 

4.15 

0.73 

0.75 

0.73 

0.71 

0.67 

0.59 

X50% 

3.99 

0.71 

0.71 

0.70 

0.67 

0.63 

0.56 

X25% 

3.83 

0.67 

0.65 

0.67 

0.60 

0.60 

0.53 

xmin 

2.42 

0.38 

0.45 

0.40 

0.42 

0.41 

0.31 

Table  36.  Summary  Statistics  3  UUV  and  50  Sensors  in  2  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

2.819 

0.496 

0.501 

0.490 

0.481 

0.457 

0.395 

“Ttrim 

2.690 

0.465 

0.483 

0.465 

0.478 

0.450 

0.385 

s2 

0.212 

0.008 

0.002 

0.008 

0.006 

0.005 

0.006 

s 

0.449 

0.085 

0.089 

0.086 

0.077 

0.066 

0.075 

cv 

0.159 

0.172 

0.178 

0.176 

0.161 

0.144 

0.189 

Xmax 

4.00 

0.69 

0.77 

0.70 

0.68 

0.59 

0.57 

X75% 

3.04 

0.54 

0.54 

0.53 

0.51 

0.51 

0.44 

x50% 

2.69 

0.47 

0.49 

0.46 

0.48 

0.45 

0.38 

X25% 

2.46 

0.44 

0.43 

0.42 

0.42 

0.43 

0.34 

xmin 

2.35 

0.39 

0.38 

0.37 

0.36 

0.33 

0.29 
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Table  37.  Summary  Statistics  3  UUV  and  50  Sensors  in  5  Lines 


EC 

SIT 

T  2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.072 

0.537 

0.521 

0.536 

0.536 

0.498 

0.445 

3.045 

0.545 

0.523 

0.533 

0.543 

0.495 

0.445 

s2 

0.082 

0.004 

0.003 

0.004 

0.003 

0.004 

0.003 

S 

0.279 

0.060 

0.057 

0.059 

0.056 

0.058 

0.055 

cv 

0.091 

0.112 

0.110 

0.110 

0.104 

0.117 

0.125 

^max 

3.51 

0.61 

0.61 

0.63 

0.63 

0.62 

0.54 

x75% 

3.28 

0.59 

0.56 

0.58 

0.57 

0.52 

0.49 

x50% 

3.05 

0.55 

0.52 

0.54 

0.54 

0.50 

0.45 

x25% 

2.96 

0.51 

0.49 

0.49 

0.51 

0.46 

0.42 

xmin 

2.41 

0.37 

0.41 

0.43 

0.41 

0.38 

0.32 

Table  38.  Summary  Statistics  3  UUV  and  100  Sensors  in  2  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

3.546 

0.630 

0.616 

0.629 

0.614 

0.574 

0.485 

-Ttrim 

3.513 

0.640 

0.613 

0.635 

0.605 

0.568 

0.488 

s2 

0.118 

0.004 

0.004 

0.006 

0.005 

0.004 

0.004 

S 

0.334 

0.060 

0.063 

0.073 

0.068 

0.059 

0.062 

CV 

0.094 

0.096 

0.102 

0.116 

0.111 

0.103 

0.128 

Xmax 

4.38 

0.76 

0.77 

0.79 

0.79 

0.70 

0.61 

X75% 

3.74 

0.65 

0.64 

0.67 

0.65 

0.61 

0.52 

X50% 

3.49 

0.64 

0.61 

0.63 

0.61 

0.57 

0.49 

X25% 

3.37 

0.58 

0.58 

0.57 

0.57 

0.55 

0.46 

xmin 

2.95 

0.53 

0.53 

0.51 

0.51 

0.47 

0.33 

Table  39.  Summary  Statistics  3  UUV  and  100  Sensors  in  5  Lines 


EC 

SIT 

t2 

t3 

t4 

t5 

t6 

n 

20 

20 

20 

20 

20 

20 

20 

X 

4.022 

0.729 

0.711 

0.712 

0.709 

0.641 

0.522 

“Ttrim 

4.093 

0.733 

0.710 

0.715 

0.728 

0.645 

0.535 

s2 

0.051 

0.003 

0.005 

0.002 

0.003 

0.001 

0.002 

s 

0.221 

0.051 

0.052 

0.046 

0.055 

0.038 

0.044 

cv 

0.055 

0.070 

0.073 

0.065 

0.078 

0.059 

0.085 

Xmax 

4.30 

0.80 

0.82 

0.79 

0.77 

0.70 

0.60 

X75% 

4.15 

0.77 

0.75 

0.74 

0.75 

0.67 

0.54 

x50% 

4.10 

0.73 

0.71 

0.72 

0.73 

0.65 

0.54 

X25% 

3.97 

0.71 

0.67 

0.68 

0.67 

0.62 

0.51 

xmin 

3.37 

0.58 

0.63 

0.60 

0.58 

0.55 

0.41 
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APPENDIX  Is  USER  INTERFACE  DEMO 


To  support  MFSA  architectural  design  and  discovery  of  user  interface 
requirements,  the  Mental  Focus  team  created  the  following  graphics  to  support 
visualizing  the  MFSA  graphic  user  interfaces  (GUI)  in  various  user  scenarios.  To 
enhance  user  acceptance,  the  team  patterned  the  GUI  design  on  typical  Department  of 
Defense  software  products,  including  the  Global  Command  and  Control  System  - 
Maritime  (GCCS-M)  currently  used  as  the  backbone  for  minefield  planning  tools  such  as 
the  Mine  Warfare  Decision  Aide  Library  (MEDAL). 

Figure  62  shows  the  MFSA  concept  GUI  during  the  creation  and  setup  of  a 
simulation  scenario  for  analysis  by  an  operational  planner. 


Figure  62.  Simulation  Setup 
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Across  the  top  of  the  window  is  the  user  navigation  and  control  section  of  the 
GUI;  including  features  common  to  most  desktop  applications.  Below  this  is  a  toolbar 
where  the  user  can  control  the  simulation,  and  toggle  user  modes  and  views.  Along  the 
left  is  a  scenario  directory,  which  presents  the  model  components  in  a  tabular  form.  This 
directory  allows  the  user  to  quickly  view  and  edit  components,  including  the  statistical 
properties  driving  the  simulation.  The  visualization  window  shows  the  geographic  layout 
of  system  components,  including  in  this  case  a  hybrid  system  of  mines,  sensors  and 
weapons,  as  well  as  the  boundaries  of  the  counter-mobility  area  and  geographic  features. 

The  team  envisions  that,  upon  opening  a  new  simulation  activity,  the  user  would 
select  the  geographic  location,  loading  in  all  environmental  and  topographic  properties 
for  the  area  of  interest.  Figure  60  shows  a  navigational  straight  with  topographic 
information  displayed  as  a  textured  over-lay  on  the  water  (black)  and  land  (orange). 
Using  a  pen  tool,  the  user  could  define  input  and  output  boundaries  as  vector,  including 
multiple  points  as  needed  for  the  required  fidelity.  The  green  boundary  in  Figure  60 
represents  the  input  source  for  threats,  where  threats  originate,  and  the  red  boundary 
provides  the  target  goal  for  navigational  success,  representing  a  failure  of  the  undersea 
weapon  system. 

For  adding  new  assets  to  the  system,  the  user  can  select  one  of  the  “add”  buttons 
across  the  top  navigation  and  place  it  visually  on  the  map  in  the  visualization  window. 
Alternatively,  the  user  can  add  components  using  the  scenario  directory  and  specify  the 
placement  in  the  asset’s  properties  using  an  input  or  randomized  location. 

Figure  63  shows  the  MFSA  concept  GUI  during  a  visualized  simulation  run.  It 
shows  a  hostile  ship,  a  red  dot,  transiting  from  the  input  boundary  along  a  navigable  path 
into  the  straight.  The  target’s  path  is  traced  with  a  line  when  visualizing  the  simulation  to 
support  understanding  the  target’s  selected  path  and  it’s  impact  on  system  performance. 
At  each  step  in  the  simulation,  MFSA  determines  the  status  of  detecting  sensors.  Figure 
63  shows  a  white  ring  around  a  detecting  sensor,  with  a  radius  equal  to  the  range  of  the 
threat  from  the  sensor.  This  allows  the  user  to  visualize  the  likely  detection  range  of  the 
sensor  had  the  threat  taken  an  alternative  path,  and  confirm  the  adequacy  of  sensor 
coverage. 
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Figure  63.  Simulation  Run 


MFSA  should  also  support  visualization  of  the  communications  transfer  between 
FUWS  components.  Figure  63  shows  a  sensor  reporting  (dashed  white  line)  to  a  mobile 
weapon  asset  battery  the  detection  of  the  hostile  warship.  As  additional  sensors  are 
triggered  and  the  system  launches  an  intercept  weapon,  MFSA  would  graphically  display 
these  milestones.  As  an  appropriate  weapon  is  identified  and  launched  toward  a  projected 
intercept  point,  the  path  of  the  weapon  would  be  displayed  as  well.  The  purpose  of 
visualizing  of  each  step  in  this  process  is  to  provide  the  user  an  understanding  of  the 
model  response,  allowing  the  user  to  understand  the  value  provided  by  individual 
components  based  on  location  and  performance  properties.  Alternatively,  the  user  could 
disable  visualizations  when  conducting  large  numbers  of  Monte  Carlo  simulations  to 
support  statistical  analysis. 

Figure  64  shows  a  potential  visualization  of  MFSA  output  data.  While  the 
reporting  features  of  MFSA  could  provide  a  catalog  of  the  simulation  record  including 
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milestone  events  such  as  the  change  in  state  of  assets  in  the  field  of  operation,  the 
selected  output  performance  parameters,  such  as  SIT  and  EC,  would  need  to  be  readily 
available  to  the  user.  The  team  also  envisioned  the  capability  to  provide  a  gradient  map, 
similar  to  what  may  be  seen  in  computational  fluid  dynamics  or  finite  element  analysis 
programs,  that  would  show  the  system  performance  across  the  area.  MFSA  could  use 
color-coding  to  indicate  areas  where  performance  achieved  a  specified  level  of 
performance  and  areas  where  the  system  assumed  risk.  In  Figure  64,  green  regions 
signify  areas  with  the  lowest  risk  of  failure  against  the  threat,  while  yellow  and  red 
regions  indicate  areas  where  the  threat  can  operate  with  relative  safety.  In  other  words, 
green  regions  are  well  defended,  while  red  are  less  so.  This  allows  the  user  to  identify 
areas  that  may  require  additional  sensors  or  weapon  coverage  and  supports  a  more 
sophisticated  system  deployment 


Figure  64.  Simulation  Output 
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